ldap identity provider to validate user names and passwords against an LDAPv3 server, using simple bind authentication.
By default, only a
kubeadmin user exists on your cluster. To specify an
identity provider, you must create a custom resource (CR) that describes
that identity provider and add it to the cluster.
OKD user names containing
During authentication, the LDAP directory is searched for an entry that matches the provided user name. If a single unique match is found, a simple bind is attempted using the distinguished name (DN) of the entry plus the provided password.
These are the steps taken:
Generate a search filter by combining the attribute and filter in the
url with the user-provided user name.
Search the directory using the generated filter. If the search does not return exactly one entry, deny access.
Attempt to bind to the LDAP server using the DN of the entry retrieved from the search, and the user-provided password.
If the bind is unsuccessful, deny access.
If the bind is successful, build an identity using the configured attributes as the identity, email address, display name, and preferred user name.
url is an RFC 2255 URL, which specifies the LDAP host and
search parameters to use. The syntax of the URL is:
For this URL:
For regular LDAP, use the string
The name and port of the LDAP server. Defaults to
The DN of the branch of the directory where all searches should start from. At the very least, this must be the top of your directory tree, but it could also specify a subtree in the directory.
The attribute to search for. Although RFC 2255 allows a
comma-separated list of attributes, only the first attribute will be used, no
matter how many are provided. If no attributes are provided, the default is to
The scope of the search. Can be either
A valid LDAP search filter. If not provided, defaults to
When doing searches, the attribute, filter, and provided user name are combined to create a search filter that looks like:
For example, consider a URL of:
When a client attempts to connect using a user name of
bob, the resulting
search filter will be
If the LDAP directory requires authentication to search, specify a
bindPassword to use to perform the entry search.
To use the identity provider, you must define an OKD
Secret object that contains the
Secret object that contains the
$ oc create secret generic ldap-secret --from-literal=bindPassword=<secret> -n openshift-config (1)
|1||The secret key containing the bindPassword for the
You can alternatively apply the following YAML to create the secret:
Identity providers use OKD
ConfigMap objects in the
namespace to contain the certificate authority bundle. These are primarily
used to contain certificate bundles needed by the identity provider.
Define an OKD
ConfigMap object containing the
certificate authority by using the following command. The certificate
authority must be stored in the
ca.crt key of the
$ oc create configmap ca-config-map --from-file=ca.crt=/path/to/ca -n openshift-config
You can alternatively apply the following YAML to create the config map:
The following custom resource (CR) shows the parameters and acceptable values for an LDAP identity provider.
apiVersion: config.openshift.io/v1 kind: OAuth metadata: name: cluster spec: identityProviders: - name: ldapidp (1) mappingMethod: claim (2) type: LDAP ldap: attributes: id: (3) - dn email: (4) - mail name: (5) - cn preferredUsername: (6) - uid bindDN: "" (7) bindPassword: (8) name: ldap-secret ca: (9) name: ca-config-map insecure: false (10) url: "ldaps://ldaps.example.com/ou=users,dc=acme,dc=com?uid" (11)
|1||This provider name is prefixed to the returned user ID to form an identity name.|
|2||Controls how mappings are established between this provider’s identities and
|3||List of attributes to use as the identity. First non-empty attribute is used. At least one attribute is required. If none of the listed attribute have a value, authentication fails. Defined attributes are retrieved as raw, allowing for binary values to be used.|
|4||List of attributes to use as the email address. First non-empty attribute is used.|
|5||List of attributes to use as the display name. First non-empty attribute is used.|
|6||List of attributes to use as the preferred user name when provisioning a user for this identity. First non-empty attribute is used.|
|7||Optional DN to use to bind during the search phase. Must be set if
|8||Optional reference to an OKD
|9||Optional: Reference to an OKD
|11||An RFC 2255 URL which specifies the LDAP host and search parameters to use.|
To whitelist users for an LDAP integration, use the
See Identity provider parameters for information on parameters, such as
mappingMethod, that are common to all identity providers.
After you install your cluster, add an identity provider to it so your users can authenticate.
Create an OKD cluster.
Create the custom resource (CR) for your identity providers.
You must be logged in as an administrator.
Apply the defined CR:
$ oc apply -f </path/to/CR>
If a CR does not exist,
Log in to the cluster as a user from your identity provider, entering the password when prompted.
$ oc login -u <username>
Confirm that the user logged in successfully, and display the user name.
$ oc whoami