$ oc create secret generic <secret_name> --from-literal=clientSecret=<secret> -n openshift-config
Configure the keystone
identity provider to integrate
your OpenShift Container Platform 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 OpenShift Container Platform with
their Keystone credentials.
Keystone is an OpenStack project that provides identity, token, catalog, and policy services.
You can configure the integration with Keystone so that the new OpenShift Container Platform 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 OpenShift Container Platform users off of the Keystone ID is more secure. 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.
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.
OpenShift Container Platform user names containing |
Identity providers use OpenShift Container Platform Secret
objects in the openshift-config
namespace to contain the client secret, client certificates, and keys.
You can define an OpenShift Container Platform Secret
object containing a string
by using the following command.
$ oc create secret generic <secret_name> --from-literal=clientSecret=<secret> -n openshift-config
You can define an OpenShift Container Platform Secret
object containing the contents of a
file, such as a certificate file, by using the following command.
$ oc create secret generic <secret_name> --from-file=/path/to/file -n openshift-config
Identity providers use OpenShift Container Platform 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.
Define an OpenShift Container Platform 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
The following custom resource (CR) shows the parameters and acceptable values for a Keystone identity provider.
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 OpenShift Container Platform configmap object containing the
PEM-encoded certificate authority bundle to use in validating server
certificates for the configured URL. |
6 | Optional: Reference to an OpenShift Container Platform Secret object containing the client
certificate to present when making requests to the configured URL. |
7 | Reference to an OpenShift Container Platform Secret object containing the key for the
client certificate. Required if tlsClientCert is specified. |
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 OpenShift Container Platform 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