Red Hat OpenShift Security | OpenShift, 30 Apr 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: OpenShift 4 OAuth Identity Providers

Description

In this video we will explore configuring OAuth to specify an identity provider with OpenShift 4. We will also walk through creating a Custom Resource (CR) that describes the identity provider. We will continue to show how users authenticate against the API and access their OpenShift Cluster.

A

A

Hi, my name is Paul Goethe's and I'm with the cloud platforms business unit here at Red Hat today, I'm going to show you how to specify and configure an identity provider with OpenShift 4 by creating a custom resource that describes that identity provider and then added to the cluster from there or facilitates a token exchange flow between OpenShift container platform and the IDP as I was introducing myself. I was actually running the installer to install my OpenShift 4 cluster on AWS platform.

A

As you can see, the cluster is ready and I'm gonna go ahead and login with the cube admin user.

A

Now that we've logged in I want you to notice that you can see that by default, only a cube admin user exists on your cluster. Now it's important to note that you can configure many types of identity providers with the wrists and all a server that comes with openshift, but for this demo, I'm going to configure HT password as an IDP to validate usernames and passwords against a flat file generated using HD password and then I'm going to configure github as an identity provider divided by usernames and passwords against github or authentication server.

A

Now to use github as an identity provider. We must register openshift as an OAuth application with github to do so, go to the menu settings and then from there we're gonna scroll all the way down to developer settings. As you can see here and then we're gonna click on new hoth application, then we're gonna give it a name, try to make it as descriptive as possible from here.

A

You need to enter the full URL for your application, home page I'm, just gonna type in your API server for now, and then the authorization callback is the same as your homepage. Url, with the identity provider name appended towards the end of the URL.

A

Now you can see we have a client ID as well as a client secret. These values are very important for us to complete the identity provider configuration and now that we have these values, we can actually go back to our openshift cluster and openshift secret.

A

To do so, we're gonna go to work, loads secrets and click on create key value secret for the GUI or we can go to the terminal and run a single command, and this command is saying I'm going to go ahead and create a secret with the name could hub secret and I'm going to embed the client secret. That github has provided me with into this github into this open ship secret. Now that we have created our a bunch of secret, our next step is to create a CR or custom resource that describes the identity provider.

A

Let's take a look at our custom resource. First of all, we can see that the client is set to OFF. If we navigate down to identity providers and respect, we can see we gave it, we gave it the name of the identity provider. You can see that the challenge is set to false, because github does not support basic auth challenge. Headers for unauthenticated token requests coming from non web clients.

A

The login is set to true because we want unauthenticated token requests from web clients like the web, console to be redirected to a login page back by this provider. Now the mapping method is set to claim the type is github and then under github we're gonna go ahead and have the client ID.

A

This is a Fae client, ID and I'm heading here from my fake application, I'm not using my actual client ID that I'll be that I'm using for this demo for security reasons, and then we have our client secret that is embedded within our openshift secret, called github secret that we just created together. So now all we have left for us to do really is to apply our github custom resource that we just created and there you go.

A

We can actually see that the cluster resource has been configured, so we can go ahead and clear the terminal and navigate back to our console to take a look before checking on the cluster auth configuration I'm gonna go ahead and check on our github secret under the open ship, config namespace, to make sure that it's there we can actually see that we have the client secret embedded. You can take a look at it in the admin format as well.

A

It looks good so now we can go ahead and navigate to our cluster auth config from here. You can actually see that github is on the list of identity providers. Again you can actually look at it in Yammer format and also notice that github is under the list of identity providers. This is good so now, before we move forward, we can actually go ahead and set up HT password as an identity provider, but now you're using a different method. We're just gonna use the GUI.

A

The mapping method is similar to github claim, but now all we have to do is upload our HT password file to open shift and click on add from here. You can actually see now we have both identity providers listed under the list of identity providers in our orth configuration.

A

This is great, so we can click on save but before we continue any further and check and make sure that HT + HT password seeker was created, we're gonna go back to work, loads, Pollitz and navigate to our open shift, authentication namespace to make sure that our pods are actually ready and up and running as you can see that the pods are in the process of getting ready, so we're gonna give them a second and there you go.

A

Let's go ahead and click on one of the pods and take a look at it and make sure that everything is quick to us. There you go, you can notice that this was created less than a minute ago. Right now. That means it's up to date. This is good. Everything looks good to me. So now we can go ahead and go back to the open shift, config namespace, to make sure that we also have the HT password secret. Alongside we github secret, and there you go. We have both secrets together. This is perfect.

A

One last look at our cluster woth config. To make sure that everything looks good now from here. All that is left for us to do is to actually log out of our cluster, and now you can see. We have three different methods you can log in as cube admin, leverage, github or HT password, but before we log in through HTTP right. Let me open that file for you and show you what's inside. There's one user in this case and the user name is Paul gh.

A

What I'm gonna do next is essentially when I log in through the content, I'm gonna type, HT, click on HT, password and I will be using this user to authenticate against OpenShift click on login, and you can see there we go. We can actually log in with a different user called Paul th and that's the same user inside my HT password file. If I click on github, you can see, we were redirected and now I'm logged in with my github credentials, seamlessly into my open ship for cluster.