1. Documentation
×

Configuring a Keystone identity provider

Configure the keystone identity provider to integrate your OKD cluster with Keystone to enable shared authentication with an OpenStack Keystone v3 server configured to store users in an internal database. This configuration allows users to log in to OKD with their Keystone credentials.

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 Keystone authentication

Keystone is an OpenStack project that provides identity, token, catalog, and policy services.

You can configure the integration with Keystone so that the new OKD users are based on either the Keystone user names or unique Keystone IDs. With both methods, users log in by entering their Keystone user name and password. Basing the OKD users on the Keystone ID is more secure because if you delete a Keystone user and create a new Keystone user with that user name, the new user might have access to the old user’s resources.

Creating the secret

You can create a TLS Secret object in the openshift-config namespace by using the oc CLI or by applying a YAML file to store client certificates and keys that identity providers require for secure communication.

Procedure

  1. Create a Secret object that contains the key and certificate by running the following command:

    $ oc create secret tls <secret_name> --key=key.pem --cert=cert.pem -n openshift-config

  2. Optional: Apply the following YAML to create the secret:

    apiVersion: v1
kind: Secret
metadata:
  name: <secret_name>
  namespace: openshift-config
type: kubernetes.io/tls
data:
  tls.crt: <base64_encoded_cert>
  tls.key: <base64_encoded_key>

Creating a 'ConfigMap'

Create a ConfigMap object in the openshift-config namespace to store the certificate authority bundle that identity providers use to validate secure connections to the remote authentication service.

Procedure

  1. Define an OKD ConfigMap object containing the certificate authority by running the following command:

    $ oc create configmap ca-config-map --from-file=ca.crt=/path/to/ca -n openshift-config

  2. Optional: 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>

    The certificate authority must be stored in the ca.crt key of the ConfigMap object.

Sample Keystone CR

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

Keystone CR
apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
  - name: keystoneidp (1)
    mappingMethod: claim (2)
    type: Keystone
    keystone:
      domainName: default (3)
      url: https://keystone.example.com:5000 (4)
      ca: (5)
        name: ca-config-map
      tlsClientCert: (6)
        name: client-cert-secret
      tlsClientKey: (7)
        name: client-key-secret
1 This provider name is prefixed to provider user names to form an identity name.
2 Controls how mappings are established between this provider’s identities and User objects.
3 Keystone domain name. In Keystone, usernames are domain-specific. Only a single domain is supported.
4 The URL to use to connect to the Keystone server (required). This must use https.
5 Optional: Reference to an OKD ConfigMap object containing the PEM-encoded certificate authority bundle to use in validating server certificates for the configured URL.
6 Optional: Reference to an OKD Secret object containing the client certificate to present when making requests to the configured URL.
7 Reference to an OKD Secret object containing the key for the client certificate. Required if tlsClientCert is specified.
Additional resources

Adding an identity provider to your cluster

Apply the identity provider custom resource (CR) to your cluster so users can authenticate with the configured identity provider.

Prerequisites

  • You installed an OKD cluster.

  • You defined the CR for your identity provider.

  • You are logged in as an administrator.

Procedure

  1. 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.

  2. Log in to the cluster with credentials from the configured identity provider by running the following command. Enter the password when prompted:

    $ oc login -u <username>

  3. Confirm that the user logged in successfully and that the username displays by running the following command:

    $ oc whoami