From 84ec84ddfaece753aae21056e9cbbd9137d456bd Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Thu, 19 Jul 2018 19:45:14 -0700 Subject: [PATCH 1/5] added a little bit more info about ingress, and added links to kub docs --- .../load-balancers-and-ingress/_index.md | 26 +++++++++++++++++++ .../load-balancers/_index.md | 4 --- 2 files changed, 26 insertions(+), 4 deletions(-) diff --git a/content/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/_index.md b/content/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/_index.md index bfc50aec574..d67a81b5151 100644 --- a/content/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/_index.md +++ b/content/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/_index.md @@ -2,3 +2,29 @@ title: Load Balancing and Ingresses weight: 3040 --- + +Within Rancher, you can setup load balancers and ingress controllers to redirect service requests. + +### Load Balancers + +After you launch an application, the app is only available within the cluster. It can't be reached from outside the cluster. + +If you want your applications to be externally accessible, you must add a load balancer to your cluster. Load balancers create a gateway for external connections to access your cluster, provided that the user knows the load balancer's IP address and the application's port number. + +Rancher supports two types of load balancers: + +- [Layer-4 Load Balancers]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/load-balancers/#layer-4-load-balancer) +- [Layer-7 Load Balancers]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/load-balancers/#layer-7-load-balancer) + +For more information, see [load balancers]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/load-balancers). + +#### Ingress + +Load Balancers can only handle one IP address per service, which means if you run multiple services in your cluster, you must have a load balancer for each service. Running multiples load balancers can be expensive. + +To address this issue, you can set up an ingress. Ingress is a controller that sits behind a load balancer. When the load balancer receives a request for one of the services running in your cluster, the load balancer passes it to your Ingress. Ingress then routes the request to the correct service based on service subdomains or path rules that you've configured. + +Ingress can provide other functionality as well, such as SSL termination and name-based virtual hosting. + +- For more information on how to setup ingress in Rancher, see [Ingress]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/ingress). +- For complete information about ingress, see the [Kubernetes Ingress Documentation](https://kubernetes.io/docs/concepts/services-networking/ingress/) diff --git a/content/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/load-balancers/_index.md b/content/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/load-balancers/_index.md index f75aa11170f..4c67b78cbe1 100644 --- a/content/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/load-balancers/_index.md +++ b/content/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/load-balancers/_index.md @@ -55,8 +55,6 @@ The benefit of using xip.io is that you obtain a working entrypoint URL immediat ## Related Links -### External Load Balancers - #### External Links - [Create an External Load Balancer](https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/) @@ -67,6 +65,4 @@ The benefit of using xip.io is that you obtain a working entrypoint URL immediat - [High Availability Installation with External Load Balancer (TCP/Layer 4)]({{< baseurl >}}/rancher/v2.x/en/installation/ha-server-install) - [Single Node Installation with External Load Balancer]({{< baseurl >}}/rancher/v2.x/en/installation/single-node-install-external-lb) -### Ingress Controller -- [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/#what-is-ingress) From 4d8bda9c13c0d8d1a7d609db799621bb828f0c59 Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Fri, 20 Jul 2018 14:46:27 -0700 Subject: [PATCH 2/5] updates based on Alena's feedback --- .../load-balancers-and-ingress/_index.md | 26 ++++++++++++++----- 1 file changed, 20 insertions(+), 6 deletions(-) diff --git a/content/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/_index.md b/content/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/_index.md index d67a81b5151..4c8e90b0d06 100644 --- a/content/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/_index.md +++ b/content/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/_index.md @@ -5,7 +5,7 @@ weight: 3040 Within Rancher, you can setup load balancers and ingress controllers to redirect service requests. -### Load Balancers +## Load Balancers After you launch an application, the app is only available within the cluster. It can't be reached from outside the cluster. @@ -18,13 +18,27 @@ Rancher supports two types of load balancers: For more information, see [load balancers]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/load-balancers). -#### Ingress +### Load Balancer Limitations -Load Balancers can only handle one IP address per service, which means if you run multiple services in your cluster, you must have a load balancer for each service. Running multiples load balancers can be expensive. +Load Balancers have a couple of limitations you should be aware of: -To address this issue, you can set up an ingress. Ingress is a controller that sits behind a load balancer. When the load balancer receives a request for one of the services running in your cluster, the load balancer passes it to your Ingress. Ingress then routes the request to the correct service based on service subdomains or path rules that you've configured. +- Load Balancers can only handle one IP address per service, which means if you run multiple services in your cluster, you must have a load balancer for each service. Running multiples load balancers can be expensive. -Ingress can provide other functionality as well, such as SSL termination and name-based virtual hosting. +- If you want to use a load balancer with a Hosted Kubernetes cluster (i.e., clusters hosted in GKE, EKS, or AKS), you must host your load balancer with the same cloud provider. For more information, view the following compatibility tables: + + - [Cloud Support for Layer-4 Load Balancing]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/load-balancers/#cloud-support-for-layer-4-load-balancing) + + - [Cloud Support for Layer-7 Load Balancing]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/load-balancers/#cloud-support-for-layer-7-load-balancing) + +## Ingress + +As mentioned in the limitations above, using a load balancer per service can be expensive. You can get around this issue using an ingress. + +Ingress is a load balancer that works in conjunction with one or more ingress controllers to dynamically route service request. When the ingress receives a request, the ingress controller(s) in your cluster program the ingress to direct the request to the correct service based on service subdomains or path rules that you've configured. + +Your ingress can either reside within your cluster or externally. Ingress and ingress controllers residing in RKE-launcher clusters are powered by [Nginx](https://www.nginx.com/). + +Ingress can provide other functionality as well, such as SSL termination, name-based virtual hosting, and more. - For more information on how to setup ingress in Rancher, see [Ingress]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/ingress). -- For complete information about ingress, see the [Kubernetes Ingress Documentation](https://kubernetes.io/docs/concepts/services-networking/ingress/) +- For complete information about ingress and ingress controllers, see the [Kubernetes Ingress Documentation](https://kubernetes.io/docs/concepts/services-networking/ingress/) From 8a4ff42b284f27eb591dc833431fbce6e126c3e8 Mon Sep 17 00:00:00 2001 From: Jan B Date: Fri, 20 Jul 2018 19:21:36 +0200 Subject: [PATCH 3/5] Revamped OpenLDAP documentation --- .../authentication/openldap/_index.md | 135 +++++++++++++----- 1 file changed, 103 insertions(+), 32 deletions(-) diff --git a/content/rancher/v2.x/en/admin-settings/authentication/openldap/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/openldap/_index.md index c577e9a2131..2777c006cac 100644 --- a/content/rancher/v2.x/en/admin-settings/authentication/openldap/_index.md +++ b/content/rancher/v2.x/en/admin-settings/authentication/openldap/_index.md @@ -7,51 +7,122 @@ aliases: _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. +If your organization uses LDAP for user authentication, you can configure Rancher to communicate with an OpenLDAP server to authenticate users. This allows Rancher admins to control access to clusters and projects based on users and groups managed externally in the organisation's central user repository, while allowing end-users to authenticate with their LDAP credentials when logging in to the Rancher UI. + +## OpenLDAP Authentication Flow + +1. When a user attempts to login with his LDAP credentials, Rancher creates an initial bind to the LDAP server using a service account with permissions to search the directory and read user/group attributes. +2. Rancher then searches the directory for the user by using a search filter based on the provided username and configured attribute mappings. +3. Once the user has been found, he is authenticated with another LDAP bind request using the user's DN and provided password. +4. Once authentication succeeded, Rancher then resolves the group memberships both from the membership attribute in the user's object and by performing a group search based on the configured user mapping attribute. ->**Prerequisites:** +> **Note:** +> +> Before you proceed with the configuration, please familiarise yourself with the concepts of [External Authentication Configuration and Principal Users]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/#external-authentication-configuration-and-principal-users). + +## Prerequisites + +Rancher must be configured with a LDAP bind account (aka service account) to search and retrieve LDAP entries pertaining to users and groups that should have access. It is recommended to not use an admin account or personal account for this purpose and instead create a dedicated account in OpenLDAP with read-only access to users and groups under the configured search base (see below). + +> **Using TLS?** > ->- 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/admin-settings/authentication/#external-authentication-configuration-and-principal-users). +> If the certificate used by the OpenLDAP server is self-signed or not from a recognised certificate authority, make sure have at hand the CA certificate (concatenated with any intermediate certificates) in PEM format. You will have to paste in this certificate during the configuration so that Rancher is able to validate the certificate chain. -1. Sign into Rancher using a local user assigned the `administrator` role (i.e., the _local principal_). +## Configuration Steps +### Open OpenLDAP Configuration -2. From the **Global** view, select **Security > Authentication** from the main menu. +1. Log into the Rancher UI using the initial local `admin` account. +2. From the **Global** view, navigate to **Security** > **Authentication** +3. Select **OpenLDAP**. The **Configure an OpenLDAP server** form will be displayed. -3. Select **OpenLDAP**. +### Configure OpenLDAP Server Settings -4. Complete the **Configure an OpenLDAP server** form. +In the section titled `1. Configure an OpenLDAP server`, complete the fields with the information specific to your server. Please refer to the following table for detailed information on the required values for each parameter. - You may need to log in to your domain controller to find the information requested in the form. +> **Note:** +> +> If you are in doubt about the correct values to enter in the user/group Search Base configuration fields, consult your LDAP administrator or refer to the section [Identify Search Base and Schema using ldapsearch]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/ad/#annex-identify-search-base-and-schema-using-ldapsearch) in the Active Directory authentication documentation. - >**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. +**Table 1: OpenLDAP server parameters** +| Parameter | Description | +|:--|:--| +| Hostname | Specify the hostname or IP address of the OpenLDAP server | +| Port | Specify the port at which the OpenLDAP server is listening for connections. Unencrypted LDAP normally uses the standard port of 389, while LDAPS uses port 636.| +| TLS | Check this box to enable LDAP over SSL/TLS (commonly known as LDAPS). You will also need to paste in the CA certificate if the server uses a self-signed/enterprise-signed certificate. | +| Server Connection Timeout | The duration in number of seconds that Rancher waits before considering the server unreachable. | +| Service Account Distinguished Name | Enter the Distinguished Name (DN) of the user that should be used to bind, search and retrieve LDAP entries. (see [Prerequisites](#prerequisites)). | +| Service Account Password | The password for the service account. | +| User Search Base | Enter the Distinguished Name of the node in your directory tree from which to start searching for user objects. All users must be descendents of this base DN. For example: "ou=people,dc=acme,dc=com".| +| Group Search Base | If your groups live under a different node than the one configured under `User Search Base` you will need to provide the Distinguished Name here. Otherwise leave this field empty. For example: "ou=groups,dc=acme,dc=com".| -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. +### Configure User/Group Schema -6. Enter your OpenLDAP username and password in **Authenticate with OpenLDAP** to confirm that Rancher is configured to use OpenLDAP authentication. +If your OpenLDAP directory deviates from the standard OpenLDAP schema, you must complete the **Customize Schema** section to match it. +Note that the attribute mappings configured in this section are used by Rancher to construct search filters and resolve group membership. It is therefore always recommended to verify that the configuration here matches the schema used in your OpenLDAP. + +> **Note:** +> +> If you are unfamiliar with the user/group schema used in the OpenLDAP server, consult your LDAP administrator or refer to the section [Identify Search Base and Schema using ldapsearch]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/ad/#annex-identify-search-base-and-schema-using-ldapsearch) in the Active Directory authentication documentation. + +#### User Schema + +The table below details the parameters for the user schema configuration. + +**Table 2: User schema configuration parameters** + +| Parameter | Description | +|:--|:--| +| Object Class | The name of the object class used for user objects in your domain. | +| Username Attribute | The user attribute whose value is suitable as a display name. | +| Login Attribute | The attribute whose value matches the username part of credentials entered by your users when logging in to Rancher. This is typically `uid`. | +| User Member Attribute | The user attribute containing the Distinguished Name of groups a user is member of. Usually this is one of `memberOf` or `isMemberOf`. | +| Search Attribute | When a user enters text to add users or groups in the UI, Rancher queries the LDAP server and attempts to match users by the attributes provided in this setting. Multiple attributes can be specified by separating them with the pipe ("\|") symbol. | +| User Enabled Attribute | If the schema of your OpenLDAP server supports a user attribute whose value can be evaluated to determine if the account is disabled or locked, enter the name of that attribute. The default OpenLDAP schema does not support this and the field should usually be left empty. | +| Disabled Status Bitmask | This is the value for a disabled/locked user account. The parameter is ignored if `User Enabled Attribute` is empty. | + +--- + +#### Group Schema + +The table below details the parameters for the group schema configuration. + +**Table 3: Group schema configuration parameters** + +| Parameter | Description | +|:--|:--| +| Object Class | The name of the object class used for group entries in your domain. | +| Name Attribute | The group attribute whose value is suitable for a display name. | +| Group Member User Attribute | The name of the **user attribute** whose format matches the group members in the `Group Member Mapping Attribute`. | +| Group Member Mapping Attribute | The name of the group attribute containing the members of a group. | +| Search Attribute | Attribute used to construct search filters when adding groups to clusters or projects in the UI. See description of user schema `Search Attribute`. | +| Group DN Attribute | The name of the group attribute whose format matches the values in the user's group membership attribute. See `User Member Attribute`. | +| Nested Group Membership | This settings defines whether Rancher should resolve nested group memberships. Use only if your organisation makes use of these nested memberships (ie. you have groups that contain other groups as members). | + +--- + +### Test Authentication + +Once you have completed the configuration, proceed by testing the connection to the OpenLDAP server. Authentication with OpenLDAP will be enabled implicitly if the test is successful. + +> **Note:** +> +> The OpenLDAP user pertaining to the credentials entered in this step will be mapped to the local principal account and assigned admin privileges in Rancher. You should therefore make a conscious decision on which LDAP account you use to perform this step. + +1. Enter the **username** and **password** for the OpenLDAP account that should be mapped to the local principal account. +2. Click **Authenticate With OpenLDAP** to test the OpenLDAP connection and finalise the setup. **Result:** - OpenLDAP authentication is configured. -- You are signed into Rancher with your OpenLDAP account (i.e., the _external principal_). +- The LDAP user pertaining to the entered credentials is mapped to the local principal (administrative) account. + +> **Note:** +> +> You will still be able to login using the locally configured `admin` account and password in case of a disruption of LDAP services. + +## Annex: Troubleshooting + +If you are experiencing issues while testing the connection to the OpenLDAP server, first double-check the credentials entered for the service account as well as the search base configuration. You may also inspect the Rancher logs to help pinpointing the problem cause. Debug logs may contain more detailed information about the error. Please refer to [How can I enable debug logging]({{< baseurl >}}/rancher/v2.x/en/faq/technical/#how-can-i-enable-debug-logging) in this documentation. From a6e59757268a9bef6dce9e559986c954d1c45909 Mon Sep 17 00:00:00 2001 From: Jan B Date: Fri, 20 Jul 2018 19:38:16 +0200 Subject: [PATCH 4/5] Updated AD docs - Added notes regarding the use of UPN vs. NetBIOS style login names. - Clarified implications of the credentials used in the the test step. --- .../authentication/ad/_index.md | 40 +++++++++++-------- 1 file changed, 23 insertions(+), 17 deletions(-) diff --git a/content/rancher/v2.x/en/admin-settings/authentication/ad/_index.md b/content/rancher/v2.x/en/admin-settings/authentication/ad/_index.md index 42307197d74..a65ebc1b138 100644 --- a/content/rancher/v2.x/en/admin-settings/authentication/ad/_index.md +++ b/content/rancher/v2.x/en/admin-settings/authentication/ad/_index.md @@ -5,7 +5,9 @@ aliases: - /rancher/v2.x/en/tasks/global-configuration/authentication/active-directory/ --- -Rancher can be configured to communicate with an existing Microsoft Active Directory server for the purpose user authentication. This allows users to use their AD account credentials for login into the Rancher UI as well as managing access to clusters and projects based on AD user identity or group membership. +If your organization uses Microsoft Active Directory as central user repository, you can configure Rancher to communicate with an Active Directory server to authenticate users. This allows Rancher admins to control access to clusters and projects based on users and groups managed externally in the Active Directory, while allowing end-users to authenticate with their AD credentials when logging in to the Rancher UI. + +Rancher uses LDAP to communicate with the Active Directory server. The authentication flow for Active Directory is therefore the same as for the [OpenLDAP authentication]({{< baseurl >}}/rancher/v2.x/en/admin-settings/authentication/openldap) integration. > **Note:** > @@ -13,11 +15,11 @@ Rancher can be configured to communicate with an existing Microsoft Active Direc ## Prerequisites -You'll need to create or obtain from your AD administrator a new AD user to use as service account for Rancher. This user must have sufficient permissions to perform searches and read attributes of users and groups under your AD domain. +You'll need to create or obtain from your AD administrator a new AD user to use as service account for Rancher. This user must have sufficient permissions to perform LDAP searches and read attributes of users and groups under your AD domain. -Usually a (non-admin) **Domain User** account should be used for this purpose, as by default such user has privileges to view, but not modify other objects in the domain partition. +Usually a (non-admin) **Domain User** account should be used for this purpose, as by default such user has read-only privileges for most objects in the domain partition. -Note however, that in some locked-down Active Directory configurations this default behaviour may not apply. In such case you will need to ensure that the service account user has both **Read** and **List Content** permissions granted either on the Base OU (enclosing users and groups) or globally for the domain. +Note however, that in some locked-down Active Directory configurations this default behaviour may not apply. In such case you will need to ensure that the service account user has at least **Read** and **List Content** permissions granted either on the Base OU (enclosing users and groups) or globally for the domain. > **Using TLS?** > @@ -46,9 +48,9 @@ In the section titled `1. Configure an Active Directory server`, complete the | Port | Specify the port at which the Active Directory server is listening for connections. Unencrypted LDAP normally uses the standard port of 389, while LDAPS uses port 636.| | TLS | Check this box to enable LDAP over SSL/TLS (commonly known as LDAPS).| | Server Connection Timeout | The duration in number of seconds that Rancher waits before considering the AD server unreachable. | -| Service Account Username | Enter the username of an AD account with read(-only) access to your domain partition that will be used by Rancher to lookup users and groups (see [Prerequisites](#prerequisites)). You must specify this username in the logon (slashed) format, e.g. "mydomain\rancheruser". | +| Service Account Username | Enter the username of an AD account with read-only access to your domain partition (see [Prerequisites](#prerequisites)). The username can be entered in NetBIOS format (e.g. "DOMAIN\serviceaccount") or UPN format (e.g. "serviceaccount@domain.com"). | | Service Account Password | The password for the service account. | -| Default Login Domain | Enter your AD domain, e.g. "acme". | +| Default Login Domain | When you configure this field with the NetBIOS name of your AD domain, usernames entered without a domain (e.g. "jdoe") will automatically be converted to a slashed, NetBIOS logon (e.g. "LOGIN_DOMAIN\jdoe") when binding to the AD server. If your users authenticate with the UPN (e.g. "jdoe@acme.com") as username then this field **must** be left empty. | | User Search Base | The Distinguished Name of the node in your directory tree from which to start searching for user objects. All users must be descendents of this base DN. For example: "ou=people,dc=acme,dc=com".| | Group Search Base | If your groups live under a different node than the one configured under `User Search Base` you will need to provide the Distinguished Name here. Otherwise leave it empty. For example: "ou=groups,dc=acme,dc=com".| @@ -74,9 +76,9 @@ The table below details the parameters for the user schema section configuration |:--|:--| | Object Class | The name of the object class used for user objects in your domain. | | Username Attribute | The user attribute whose value is suitable as a display name. | -| Login Attribute | The attribute whose value matches the username part of your users AD credentials, ie. what they would enter when logging in to Rancher. | +| Login Attribute | The attribute whose value matches the username part of credentials entered by your users when logging in to Rancher. If your users authenticate with their UPN (e.g. "jdoe@acme.com") as username then this field must normally be set to `userPrincipalName`. Otherwise for the old, NetBIOS-style logon names (e.g. "jdoe") it's usually `sAMAccountName`. | | User Member Attribute | The attribute containing the groups that a user is a member of. | -| Search Attribute | When a user enters text to add users or groups, Rancher queries the AD server and attempts to match fields by the attributes provided in this setting. Multiple attributes can be specified by separating them with the pipe ("\|") symbol. As of Rancher v2.0.1, this parameter defaults to: "sAMAccountName\|sn\|givenName".| +| Search Attribute | When a user enters text to add users or groups in the UI, Rancher queries the AD server and attempts to match users by the attributes provided in this setting. Multiple attributes can be specified by separating them with the pipe ("\|") symbol. To match UPN usernames (e.g. jdoe@acme.com) you should usually set the value of this field to `userPrincipalName`. | | User Enabled Attribute | The attribute containing an integer value representing a bitwise enumeration of user account flags. Rancher uses this to determine if a user account is disabled. You should normally leave this set to the AD standard `userAccountControl`. | | Disabled Status Bitmask | This is the value of the `User Enabled Attribute` designating a disabled user account. You should normally leave this set to the default value of "2" as specified in the Microsoft Active Directory schema (see [here](https://docs.microsoft.com/en-us/windows/desktop/adschema/a-useraccountcontrol#remarks)). | @@ -102,23 +104,23 @@ The table below details the parameters for the group schema configuration. ### Test Authentication -When you have completed the configuration, proceed by testing the connection to the AD server with your own AD credentials. +Once you have completed the configuration, proceed by testing the connection to the AD server. Authentication with the configured Active Directory will be enabled implicitly if the test is successful. > **Note:** > -> On completing this step of the configuration, the AD user pertaining to the credentials entered here will be mapped to the local principal account. You should therefore ensure to specifically enter credentials of an AD account that you want to be assigned the administrative role in Rancher going forward. +> The AD user pertaining to the credentials entered in this step will be mapped to the local principal account and assigned admin privileges in Rancher. You should therefore make a conscious decision on which AD account you use to perform this step. -1. Enter the **username** and **password** for your AD account. -2. Click **Authenticate with Active Directory** to test the Active Directory connection and map this user to the local admin account. +1. Enter the **username** and **password** for the AD account that should be mapped to the local principal account. +2. Click **Authenticate with Active Directory** to finalise the setup. **Result:** -- AD authentication is configured. -- You are signed into Rancher with your AD account (mapped to the local user assigned the administrator role, ie. the local principal account). +- Active Directory authentication has been enabled. +- You have been signed into Rancher as administrator using the provided AD credentials. > **Note:** > -> You will still be able to login using the locally configured `admin` account and password in case of a disruption of AD services. +> You will still be able to login using the locally configured `admin` account and password in case of a disruption of LDAP services. ## Annex: Identify Search Base and Schema using ldapsearch @@ -159,7 +161,11 @@ The output of the above `ldapsearch` query also allows to determine the correct - `Login Attribute`: **sAMAccountName** [3] - `User Member Attribute`: **memberOf** [4] -With regards to the `Search Attribute` parameter, it makes sense here to set it to **sAMAccountName|name**. This will allow users to be added in the Rancher UI both by entering their username or full name. +> **Note:** +> +> If the AD users in our organisation were to authenticate with their UPN (e.g. jdoe@acme.com) instead of the short logon name, then we would have to set the `Login Attribute` to **userPrincipalName** instead. + +We'll also set the `Search Attribute` parameter to **sAMAccountName|name**. That way users can be added to clusters/projects in the Rancher UI either by entering their username or full name. ### Identify Group Schema @@ -188,4 +194,4 @@ In the same way, we can observe that the value in the **memberOf** attribute in ## Annex: Troubleshooting -If you are experiencing issues while testing the connection to the Active Directory server, first double-check the credentials entered for the service account as well as the search base configuration. You may also inspect the Rancher logs to help pinpointing the issue cause. Please refer to [How can I enable debug logging]({{< baseurl >}}/rancher/v2.x/en/faq/technical/#how-can-i-enable-debug-logging) in this documentation. \ No newline at end of file +If you are experiencing issues while testing the connection to the Active Directory server, first double-check the credentials entered for the service account as well as the search base configuration. You may also inspect the Rancher logs to help pinpointing the problem cause. Debug logs may contain more detailed information about the error. Please refer to [How can I enable debug logging]({{< baseurl >}}/rancher/v2.x/en/faq/technical/#how-can-i-enable-debug-logging) in this documentation. From d5412946c0a212918c1b898b8c022de0d16013aa Mon Sep 17 00:00:00 2001 From: Mark Bishop Date: Fri, 20 Jul 2018 18:49:05 -0700 Subject: [PATCH 5/5] update per Denise's feedback --- .../load-balancers-and-ingress/_index.md | 12 +++++++----- .../load-balancers/_index.md | 4 ++-- 2 files changed, 9 insertions(+), 7 deletions(-) diff --git a/content/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/_index.md b/content/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/_index.md index 4c8e90b0d06..b9ceb038722 100644 --- a/content/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/_index.md +++ b/content/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/_index.md @@ -24,21 +24,23 @@ Load Balancers have a couple of limitations you should be aware of: - Load Balancers can only handle one IP address per service, which means if you run multiple services in your cluster, you must have a load balancer for each service. Running multiples load balancers can be expensive. -- If you want to use a load balancer with a Hosted Kubernetes cluster (i.e., clusters hosted in GKE, EKS, or AKS), you must host your load balancer with the same cloud provider. For more information, view the following compatibility tables: +- If you want to use a load balancer with a Hosted Kubernetes cluster (i.e., clusters hosted in GKE, EKS, or AKS), you must host your load balancer with the same cloud provider. Please review the compatibility tables regarding support for load balancers based on how you've provisioned your clusters: - - [Cloud Support for Layer-4 Load Balancing]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/load-balancers/#cloud-support-for-layer-4-load-balancing) - - [Cloud Support for Layer-7 Load Balancing]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/load-balancers/#cloud-support-for-layer-7-load-balancing) + - [Support for Layer-4 Load Balancing]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/load-balancers/#support-for-layer-4-load-balancing) + + - [Support for Layer-7 Load Balancing]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/load-balancers/#support-for-layer-7-load-balancing) ## Ingress As mentioned in the limitations above, using a load balancer per service can be expensive. You can get around this issue using an ingress. -Ingress is a load balancer that works in conjunction with one or more ingress controllers to dynamically route service request. When the ingress receives a request, the ingress controller(s) in your cluster program the ingress to direct the request to the correct service based on service subdomains or path rules that you've configured. +Ingress is a set or rules that act as a load balancer. Ingress works in conjunction with one or more ingress controllers to dynamically route service requests. When the ingress receives a request, the ingress controller(s) in your cluster program the load balancer to direct the request to the correct service based on service subdomains or path rules that you've configured. -Your ingress can either reside within your cluster or externally. Ingress and ingress controllers residing in RKE-launcher clusters are powered by [Nginx](https://www.nginx.com/). +Your load balancer can either reside within your cluster or externally. Ingress and ingress controllers residing in RKE-launcher clusters are powered by [Nginx](https://www.nginx.com/). Ingress can provide other functionality as well, such as SSL termination, name-based virtual hosting, and more. - For more information on how to setup ingress in Rancher, see [Ingress]({{< baseurl >}}/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/ingress). - For complete information about ingress and ingress controllers, see the [Kubernetes Ingress Documentation](https://kubernetes.io/docs/concepts/services-networking/ingress/) + diff --git a/content/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/load-balancers/_index.md b/content/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/load-balancers/_index.md index 4c67b78cbe1..486fa0126f0 100644 --- a/content/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/load-balancers/_index.md +++ b/content/rancher/v2.x/en/kubernetes-in-rancher/load-balancers-and-ingress/load-balancers/_index.md @@ -10,7 +10,7 @@ Kubernetes supports load balancing in two ways: Layer-4 Load Balancing and Layer Layer-4 load balancer (or the external load balancer) forwards traffic to Nodeports. Layer-4 load balancer allows you to forward both HTTP and TCP traffic. Layer-4 load balancer is supported by the underlying cloud provider. As a result, when you deploy RKE clusters on bare metal servers and vSphere clusters, layer-4 load balancer is not supported. -### Cloud Support for Layer-4 Load Balancing +### Support for Layer-4 Load Balancing Support for layer-4 load balancer varies based on the underlying cloud provider. @@ -28,7 +28,7 @@ RKE on Custom Hosts
(e.g. bare-metal servers) | Not Supported Layer-7 load balancer (or the ingress controller) supports host and path-based load balancing and SSL termination. Layer-7 load balancer only forwards HTTP and HTTPS traffic and therefore they listen on ports 80 and 443 only. Cloud providers such as Amazon and Google support layer-7 load balancer. In addition, RKE clusters deploys the Nginx Ingress Controller. -### Cloud Support for Layer-7 Load Balancing +### Support for Layer-7 Load Balancing Support for layer-7 load balancer varies based on the underlying cloud provider.