Configuring a GitHub or GitHub Enterprise identity provider - Configuring identity providers | Authentication and authorization

Identity providers in OKD
About GitHub authentication
Registering a GitHub application
Creating the secret
Creating a config map
Sample GitHub CR
Adding an identity provider to your cluster

Configure the github identity provider to validate user names and passwords against GitHub or GitHub Enterprise’s OAuth authentication server. OAuth facilitates a token exchange flow between OKD and GitHub or GitHub Enterprise.

You can use the GitHub integration to connect to either GitHub or GitHub Enterprise. For GitHub Enterprise integrations, you must provide the hostname of your instance and can optionally provide a ca certificate bundle to use in requests to the server.

The following steps apply to both GitHub and GitHub Enterprise unless noted.

Identity providers in OKD

You can configure identity providers by creating a custom resource (CR) that describes the provider and adding it to the cluster. Identity providers enable user authentication in OKD beyond the default kubeadmin user.

OKD usernames containing /, :, and % are not supported.

About GitHub authentication

Configuring GitHub authentication allows users to log in to OKD with their GitHub credentials. To prevent anyone with any GitHub user ID from logging in to your OKD cluster, you can restrict access to only those in specific GitHub organizations.

Registering a GitHub application

To use GitHub or GitHub Enterprise as an identity provider, you must register an application to use.

Procedure

Register an application on GitHub:
- For GitHub, click Settings → Developer settings → OAuth Apps → Register a new OAuth application.
- For GitHub Enterprise, go to your GitHub Enterprise home page and then click Settings → Developer settings → Register a new application.
Enter an application name, for example My OpenShift Install.
Enter a homepage URL, such as https://oauth-openshift.apps.<cluster-name>.<cluster-domain>.
Optional: Enter an application description.

Enter the authorization callback URL, where the end of the URL contains the identity provider name:

https://oauth-openshift.apps.<cluster-name>.<cluster-domain>/oauth2callback/<idp-provider-name>

For example:

https://oauth-openshift.apps.openshift-cluster.example.com/oauth2callback/github

Click Register application. GitHub provides a client ID and a client secret. You need these values to complete the identity provider configuration.

Creating the secret

Create a Secret in the openshift-config namespace to store identity provider client secrets, certificates, or keys, so the OAuth custom resource (CR) can reference them.

Procedure

Create a Secret object containing the client secret by running the following command:

$ oc create secret generic <secret_name> --from-literal=clientSecret=<secret> -n openshift-config

Optional: Apply the following YAML to create the secret:

apiVersion: v1
kind: Secret
metadata:
  name: <secret_name>
  namespace: openshift-config
type: Opaque
data:
  clientSecret: <base64_encoded_client_secret>

Create a Secret object from a file by running the following command:

$ oc create secret generic <secret_name> --from-file=<path_to_file> -n openshift-config

Creating a config map

Identity providers use OKD ConfigMap objects in the openshift-config namespace to contain the certificate authority bundle. These are primarily used to contain certificate bundles needed by the identity provider.

This procedure is only required for GitHub Enterprise.

Procedure

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 ConfigMap object.

$ 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:

apiVersion: v1
kind: ConfigMap
metadata:
  name: ca-config-map
  namespace: openshift-config
data:
  ca.crt: |
    <CA_certificate_PEM>

Sample GitHub CR

The following custom resource (CR) shows the parameters and acceptable values for a GitHub identity provider.

GitHub CR

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
  - name: githubidp (1)
    mappingMethod: claim (2)
    type: GitHub
    github:
      ca: (3)
        name: ca-config-map
      clientID: {...} (4)
      clientSecret: (5)
        name: github-secret
      hostname: ... (6)
      organizations: (7)
      - myorganization1
      - myorganization2
      teams: (8)
      - myorganization1/team-a
      - myorganization2/team-b

1	This provider name is prefixed to the GitHub numeric user ID to form an identity name. It is also used to build the callback URL.
2	Controls how mappings are established between this provider’s identities and `User` objects.
3	Optional: Reference to an OKD `ConfigMap` object containing the PEM-encoded certificate authority bundle to use in validating server certificates for the configured URL. Only for use in GitHub Enterprise with a non-publicly trusted root certificate.
4	The client ID of a registered GitHub OAuth application. The application must be configured with a callback URL of `https://oauth-openshift.apps.<cluster-name>.<cluster-domain>/oauth2callback/<idp-provider-name>`.
5	Reference to an OKD `Secret` object containing the client secret issued by GitHub.
6	For GitHub Enterprise, you must provide the hostname of your instance, such as `example.com`. This value must match the GitHub Enterprise `hostname` value in in the `/setup/settings` file and cannot include a port number. If this value is not set, then either `teams` or `organizations` must be defined. For GitHub, omit this parameter.
7	The list of organizations. Either the `organizations` or `teams` field must be set unless the `hostname` field is set, or if `mappingMethod` is set to `lookup`. Cannot be used in combination with the `teams` field.
8	The list of teams. Either the `teams` or `organizations` field must be set unless the `hostname` field is set, or if `mappingMethod` is set to `lookup`. Cannot be used in combination with the `organizations` field.

If organizations or teams is specified, only GitHub users that are members of at least one of the listed organizations will be allowed to log in. If the GitHub OAuth application configured in clientID is not owned by the organization, an organization owner must grant third-party access to use this option. This can be done during the first GitHub login by the organization’s administrator, or from the GitHub organization settings.

Additional resources

See Identity provider parameters for information on parameters, such as mappingMethod, that are common to all identity providers.

Adding an identity provider to your cluster

Apply the OAuth custom resource (CR) to add an identity provider to your cluster so users can authenticate with external credentials instead of the default kubeadmin user.

Prerequisites

You installed an OKD cluster.
You defined the CR for your identity provider.
You are logged in as an administrator.

Procedure

Apply the defined CR by running the following command:

$ oc apply -f </path/to/CR>

If a CR does not exist, oc apply creates a new CR and might trigger the following warning: Warning: oc apply should be used on resources created by either oc create --save-config or oc apply. In this case you can safely ignore this warning.

Obtain a token from the OAuth server.

As long as the kubeadmin user has been removed, the oc login command provides instructions on how to access a web page where you can retrieve the token.

You can also access this page from the web console by navigating to (?) Help → Command Line Tools → Copy Login Command.
Log in to the cluster by running the following command, passing in the token to authenticate:
```
$ oc login --token=<token>
```
This identity provider does not support logging in with a username and password.
Confirm that the user logged in successfully and that the username displays by running the following command:
```
$ oc whoami
```