From 395d2d0bc6b9b2699e78168b9aafde6102569c20 Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Fri, 8 Jun 2018 14:45:24 -0700 Subject: [PATCH] broke up global config concept, corrected resultant broken links, re-weighted topics --- .../concepts/global-configuration/_index.md | 291 +----------------- .../authentication/_index.md | 52 ++++ .../node-drivers/_index.md | 10 + .../node-templates/_index.md | 9 + .../pod-security-policies/_index.md | 19 ++ .../global-configuration/server-url/_index.md | 9 + .../users-permissions-roles/_index.md | 192 ++++++++++++ .../adding-a-pod-security-policy/_index.md | 2 +- .../authentication/_index.md | 2 +- .../authentication/active-directory/_index.md | 2 +- .../authentication/github/_index.md | 2 +- .../global-configuration/catalog/_index.md | 2 +- .../node-drivers/_index.md | 6 +- .../password-reset/_index.md | 2 +- .../pod-security-policies/_index.md | 2 +- .../global-configuration/roles/_index.md | 8 +- .../global-configuration/server-url/_index.md | 2 +- 17 files changed, 313 insertions(+), 299 deletions(-) create mode 100644 content/rancher/v2.x/en/concepts/global-configuration/authentication/_index.md create mode 100644 content/rancher/v2.x/en/concepts/global-configuration/node-drivers/_index.md create mode 100644 content/rancher/v2.x/en/concepts/global-configuration/node-templates/_index.md create mode 100644 content/rancher/v2.x/en/concepts/global-configuration/pod-security-policies/_index.md create mode 100644 content/rancher/v2.x/en/concepts/global-configuration/server-url/_index.md create mode 100644 content/rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/_index.md diff --git a/content/rancher/v2.x/en/concepts/global-configuration/_index.md b/content/rancher/v2.x/en/concepts/global-configuration/_index.md index 76869cbf670..f4f7545d47c 100644 --- a/content/rancher/v2.x/en/concepts/global-configuration/_index.md +++ b/content/rancher/v2.x/en/concepts/global-configuration/_index.md @@ -1,290 +1,13 @@ --- title: Global Configuration -weight: 2075 +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. -## Authentication +- [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) -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 -- GitHub - -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 authentication 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. - -## Users, Global Permissions, and Roles - -Within Rancher, each user authenticates as a _user_, which is a login that grants you access to Rancher. As mentioned previously, users can either be local or external. - -After you configure external authentication, the users that display on 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 create 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 enforce) - - -#### Membership and Role Assignment - -The projects and clusters accessible to non-administrative user 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 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. - -#### 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. - -## Rancher Server URL - -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**. - -## Pod Security Policies - -_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. - -## Node Drivers - -Out-of-the-box, Rancher provides support for creating clusters using many popular cloud providers: Amazon EC2, Azure, DigitalOcean, and so on. However, you may want to create a cluster using another cloud provider. In these scenarios, you can create a custom node driver for the cloud provider and point Rancher toward it. - -For more information on creating node drivers, see [https://github.com/rancher/ui-driver-skel](https://github.com/rancher/ui-driver-skel). - -## Node Templates - -You can create new clusters within Rancher using _node templates_. A node template is a virtual machine image used to create a Kubernetes cluster. While creating a cluster, Rancher will prompt you for an image to use as a template. Follow the directions on screen to create the template. During cluster creation, Rancher clones the template and installs different Kubernetes components. - -After you add a node template to Rancher, its stored by the system so that you can use it when creating another cluster later. Node templates are bound to your login. After you add a template, you can remove them from your user profile. - - 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 new file mode 100644 index 00000000000..cded32c8152 --- /dev/null +++ b/content/rancher/v2.x/en/concepts/global-configuration/authentication/_index.md @@ -0,0 +1,52 @@ +--- +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 +- GitHub + +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 authentication 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/concepts/global-configuration/node-drivers/_index.md b/content/rancher/v2.x/en/concepts/global-configuration/node-drivers/_index.md new file mode 100644 index 00000000000..943c9c0d4da --- /dev/null +++ b/content/rancher/v2.x/en/concepts/global-configuration/node-drivers/_index.md @@ -0,0 +1,10 @@ +--- +title: Node Drivers +weight: 100 +--- + +Out-of-the-box, Rancher provides support for creating clusters using many popular cloud providers: Amazon EC2, Azure, DigitalOcean, and so on. However, you may want to create a cluster using another cloud provider. In these scenarios, you can create a custom node driver for the cloud provider and point Rancher toward it. + +For more information on creating node drivers, see [https://github.com/rancher/ui-driver-skel](https://github.com/rancher/ui-driver-skel). + + diff --git a/content/rancher/v2.x/en/concepts/global-configuration/node-templates/_index.md b/content/rancher/v2.x/en/concepts/global-configuration/node-templates/_index.md new file mode 100644 index 00000000000..31d32312ba3 --- /dev/null +++ b/content/rancher/v2.x/en/concepts/global-configuration/node-templates/_index.md @@ -0,0 +1,9 @@ +--- +title: Node Templates +weight: 125 +--- + +You can create new clusters within Rancher using _node templates_. A node template is a virtual machine image used to create a Kubernetes cluster. While creating a cluster, Rancher will prompt you for an image to use as a template. Follow the directions on screen to create the template. During cluster creation, Rancher clones the template and installs different Kubernetes components. + +After you add a node template to Rancher, its stored by the system so that you can use it when creating another cluster later. Node templates are bound to your login. After you add a template, you can remove them from your user profile. + 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 new file mode 100644 index 00000000000..7e635fa3235 --- /dev/null +++ b/content/rancher/v2.x/en/concepts/global-configuration/pod-security-policies/_index.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/concepts/global-configuration/server-url/_index.md b/content/rancher/v2.x/en/concepts/global-configuration/server-url/_index.md new file mode 100644 index 00000000000..a7bdb887aa8 --- /dev/null +++ b/content/rancher/v2.x/en/concepts/global-configuration/server-url/_index.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/concepts/global-configuration/users-permissions-roles/_index.md b/content/rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/_index.md new file mode 100644 index 00000000000..63267d81cef --- /dev/null +++ b/content/rancher/v2.x/en/concepts/global-configuration/users-permissions-roles/_index.md @@ -0,0 +1,192 @@ +--- +title: Users, Global Persmissions, and Roles +weight: 15 +--- + +Within Rancher, each user authenticates as a _user_, which is a login that grants you access to Rancher. As mentioned previously, users can either be local or external. + +After you configure external authentication, the users that display on 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 create 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 enforce) + + +#### Membership and Role Assignment + +The projects and clusters accessible to non-administrative user 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 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. + +#### 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/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 5e022550928..ad2d8180bd7 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 @@ -15,7 +15,7 @@ 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/concepts/global-configuration/pod-security-policies). ## Cluster Creation: Adding a Default Pod Security Policy 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 index 397bae25447..8d03c40d7d2 100644 --- a/content/rancher/v2.x/en/tasks/global-configuration/authentication/_index.md +++ b/content/rancher/v2.x/en/tasks/global-configuration/authentication/_index.md @@ -1,6 +1,6 @@ --- title: Authentication -weight: 3075 +weight: 50 --- You have three options for user authentication in Rancher: 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 index 8f55538b31f..9105b6fb27a 100644 --- 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 @@ -8,7 +8,7 @@ In environments using Microsoft Active Directory (AD), you can configure Rancher >**Prerequisites:** > >- Create a service account in Active Directory with `read-only` access. {{< product >}} uses this account to verify group membership when a user makes a request using an API key. ->- Read [External Authentication Configuration and Principal Users]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/#external-authentication-configuration-and-principal-users). +>- 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_). 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 index 95e0cc03f1c..fce70517eaa 100644 --- 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 @@ -5,7 +5,7 @@ weight: 3075 In environments using GitHub, you can configure Rancher to allow sign on using GitHub credentials. ->**Prerequisties:** Read [External Authentication Configuration and Principal Users]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/#external-authentication-configuration-and-principal-users). +>**Prerequisties:** 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_). diff --git a/content/rancher/v2.x/en/tasks/global-configuration/catalog/_index.md b/content/rancher/v2.x/en/tasks/global-configuration/catalog/_index.md index 7ff7132e0f2..e088b7935b1 100644 --- a/content/rancher/v2.x/en/tasks/global-configuration/catalog/_index.md +++ b/content/rancher/v2.x/en/tasks/global-configuration/catalog/_index.md @@ -1,6 +1,6 @@ --- title: Catalog -weight: 3026 +weight: 1000 draft: true --- 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 ed38e8fabf2..38aaf39fd97 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 @@ -1,12 +1,12 @@ --- title: Node Drivers -weight: 3050 +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/#global-permissions) ->- [Custom Global Permissions]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/#custom-global-permissions) with the [Manage Node Drivers]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/#global-permissions-reference) role assigned. +>- [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. ## Adding Custom Node Drivers diff --git a/content/rancher/v2.x/en/tasks/global-configuration/password-reset/_index.md b/content/rancher/v2.x/en/tasks/global-configuration/password-reset/_index.md index a4c2e526957..4e466369828 100644 --- a/content/rancher/v2.x/en/tasks/global-configuration/password-reset/_index.md +++ b/content/rancher/v2.x/en/tasks/global-configuration/password-reset/_index.md @@ -1,6 +1,6 @@ --- title: Password Reset -weight: 3175 +weight: 75 draft: true --- 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 index b728a458830..1235493382e 100644 --- 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 @@ -1,6 +1,6 @@ --- title: Pod Security Policies -weight: 3150 +weight: 125 --- ## Creating Pod Security Policies 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 index f3c74018ea3..4fcb840b2e6 100644 --- a/content/rancher/v2.x/en/tasks/global-configuration/roles/_index.md +++ b/content/rancher/v2.x/en/tasks/global-configuration/roles/_index.md @@ -1,6 +1,6 @@ --- title: Roles -weight: 3100 +weight: 100 --- Within Rancher, _roles_ determine what actions a user can make within a cluster or project. @@ -10,8 +10,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/#global-permissions). ->- [Custom Global Permissions]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/#custom-global-permissions) with the [Manage Roles]({{< baseurl >}}/rancher/v2.x/en/concepts/global-configuration/#global-permissions-reference) role assigned. +>- [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 @@ -23,7 +23,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/#locked-roles). +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. 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 index c980796ef8a..f4d9df8e93f 100644 --- 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 @@ -1,6 +1,6 @@ --- title: Rancher Server URL -weight: 3125 +weight: 25 --- ## Updating the {{< product >}} Server URL