Appendix D. Configuring identity providers

Many different user databases are available to IT professionals for managing access and authentication. To interoperate with as many of these as possible, OpenShift provides 11 identity providers that interface with various user databases, including the Allow All provider that you’ve been using in your cluster up to this point. These providers are as follows:

  • Allow All— Allows any username and non-empty password to log in
  • Deny All— Doesn’t allow any usernames and passwords to log in
  • htpasswd— Authenticates with Apache htpasswd database files
  • Keystone— Uses OpenStack Keystone as the authentication source
  • LDAP— Authenticates against an LDAP provider like openLDAP
  • Basic— Uses Apache Basic authentication on a remote server to authenticate users
  • Request Header— Uses custom HTTP headers for user authentication
  • GitHub— Authenticates with GitHub using OAuth
  • GitLab— Authenticates with GitLab using OAuth
  • Google— Uses Google OpenID Connect for authentication
  • OpenID Connect— Uses OpenID Connect with a source other than Google

Different authentication providers have different options that are specific to each provider’s unique format. For example, the options available for the htpasswd provider are different than those required for the GitHub provider, because these providers access such different user databases.

In the next section, you’ll change your OpenShift cluster’s configuration to stop using the Allow All provider and start using htpasswd provider. To use this provider, you’ll need to create an htpasswd database file on the master server.

Why is htpasswd spelled this way?

The htpasswd utility is an old one. It goes all the way back to the first versions of the Apache web server in the later 1990s. Back then, computers had so much less memory that the name of an application could affect system performance.

Application names were typically limited to eight characters. To fit this tight requirement, characters were often removed wherever possible—and thus htpasswd was born.

D.1. Introduction to htpasswd

The htpasswd provider uses Apache-style htpasswd files for authentication. These are simple databases that contain a list of usernames and their corresponding passwords in an encrypted format. Each line in the file represents a user. The user and password sections are separated with a colon (:). The password section includes the algorithm that was used to encrypt the password, encapsulated by $ characters, and the encrypted password itself. Here’s an example htpasswd file with two users, admin and developer: 

admin:$apr1$vUqfPZ/D$sTL5RCy1m5kS73bC8GA3F1              1
developer:$apr1$oKuOUw1t$CEJSFcVXDH5Jcq7VDF5pU/

  • 1 admin user with a password encrypted using the default apr1 algorithm

You create htpasswd files using the htpasswd command-line tool. In appendix A, you installed this tool on your master server. By default, the htpasswd tool uses a custom encryption algorithm based on MD5 hashing.

Note

Full documentation on the Apache htpasswd application and file format is available at http://mng.bz/ZqaG. Full documentation on possible encryption formats is available at http://mng.bz/3CVh.

D.2. Creating the htpasswd database

To create an htpasswd database file, you need to SSH to your master server. On the master server, the configuration files for the OpenShift master processes are in /etc/origin/master. There, you’ll create an htpasswd file called openshift.htpasswd with three users—developer, project-admin, and admin—to act as the database for the htpasswd provider to interact with.

Tip

The location of the htpasswd file is important. Be sure to take note, because you’ll need it in the next section.

You need to run the htpasswd command to add each user. The first time you run the command, be sure to include the -c option to create the new htpasswd file.

Tip

Be sure to only use the -c option the first time, or it will overwrite your file each time. The -i option takes the password information from the command’s standard input. Without this option, the tool will prompt you twice for the password through an interactive prompt.

Use the following commands to create the htpasswd file with three users: 

# echo developer | htpasswd -i -c
 /etc/origin/master/openshift.htpasswd  developer                  1
Adding password for user developer

# echo project-admin | htpasswd -i
   /etc/origin/master/openshift.htpasswd project-admin             2
Adding password for user project-admin

# echo admin | htpasswd -i /etc/origin/master/openshift.htpasswd
 admin                                                             3
Adding password for user admin

  • 1 Creates the file and adds the developer user
  • 2 Adds the project-admin user
  • 3 Adds the admin user

With your htpasswd database created and populated with users, you’re ready to use it for authentication in OpenShift. To configure your new identity provider, you need to edit the configuration for your OpenShift master server. That’s what you’ll do in the next section.

D.3. Changing authentication providers

The configuration file for your OpenShift master is /etc/origin/master/master-config.yaml, and it’s more than 150 lines long. When you configured OpenShift, this section enabled the default Allow All provider that we discussed earlier. The following options are common to all providers:

  • challenge—Defaults to true. Ensures that web clients receive challenge HTTP headers. These headers instruct non-web clients like the oc command-line tool to be sure users are logged in before access is granted.
  • login—Defaults to true. Redirects unauthenticated sessions to the login page for the provider.
  • mappingMethod—Defines how users interact with the user database. The default value, claim, provisions a new user with the preferred login if the name isn’t available.

We’ll concentrate on the identityProviders stanza. This section controls which authentication providers are implemented in OpenShift. Here’s a default identityProviders section from master-config.yaml: 

identityProviders:
  - challenge: true
    login: true
    mappingMethod: claim
    name: allow_all                                1
    provider:
      apiVersion: v1
      kind: AllowAllPasswordIdentityProvider       2

  • 1 Name for the provider
  • 2 Provider to use
Note

You can find full information about configurations for all the identity providers at http://mng.bz/bjMJ.

The options for the htpasswd identity provider are similar to those of the Allow All provider. It requires one additional option: a file parameter that references the location of your htpasswd database file. The other big difference is the kind value, which is the name of the provider you want to use. In this case, you need to make sure the value for kind is HTPasswdPasswordIdentityProvider.

To configure the htpasswd provider, edit the identityProviders section in your master-config.yaml file as shown next.

Listing D.1. master-config.yaml configured to access your htpasswd database 
identityProviders:
- name: my_htpasswd_provider                            1
  challenge: true
  login: true
  mappingMethod: claim
  provider:
    apiVersion: v1
    kind: HTPasswdPasswordIdentityProvider              2
    file: /etc/origin/master/openshift.htpasswd         3

  • 1 Name for your new provider
  • 2 kind value
  • 3 Location of the htpasswd database file

After you make the changes and save your new configuration, restart the OpenShift master services with the following command:

systemctl restart origin-master

Once the origin-master service is restored, the new configuration is in effect. You can verify this by attempting to log in as the dev user you’ve been using in your cluster. Access should be denied at this point. Access for your newly created users—developer, project-admin, and admin—should work, with their configured passwords.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset