- [Instructor] Okay, welcome back. In this demo, I'm going to show you how to set up a new IDP, or identity provider, within the cluster, create a new dedicated identity, and assign it cluster admin permissions. This will allow us to remove the temporary kubeadmin credential which was created at installation time. To begin with, I'll jump over into the runsheet, and under step eight, copy the first two commands. 

Back within the terminal I'll paste them and kick them off. Now before we progress, let's quickly explain what this command does. The htpasswd command allows us to create a file that contains a username password credential stored in an encrypted form. This is a basic form of a credential database and will be sufficient for the purposes of this demo. In a real-world production setup, you would likely use something more robust with better management capabilities, for example, LDAP. The command that I have just executed created a new credential pair made up of a username of devuser1 with a password of blah. This gets stored in secure form within a file named users.htpasswd. The dash c parameter tells the command to generate the users.htpasswd file. The dash uppercase B parameter tells the command to use bcrypt to encrypt the password. And the dash lowercase b parameter tells the command to perform the operations in batch mode, meaning it avoids prompting you for each user's password when you execute it. 

Using the cat command to output the contents of the file, you can see that the devuser1 password is indeed encrypted. Okay, now that we have this file, let's jump back into the admin console and navigate to the Administration, Cluster Settings, Global Configuration, OAuth option, like so. Under the OAuth section I'll click the Add button. Here we can see all of the available IDP options. 

We will proceed with the htpasswd option. I now need to browse to and supply the htpasswd file that we just generated, and upload it like so. Back within the terminal, we can actually now query for the new OAauth configuration that we have just applied by executing the oc get oauth, and oc describe oauth cluster commands, like so. Here we can see under the Identity Providers section that indeed our htpasswd setup has been applied successfully. At this stage we can jump back into the web console and log out and attempt to log back in as the new devuser1. You can see here on the login page that we now have two different authentication mechanisms, the original one which allows us to log in with the temporary kubeadmin credential, and the new one via the htpasswd mechanism that we just configured. I'll select this option and then enter in the new devuser1 credentials, in this case, blah is the password. And as you can see, we have authed in successfully. As expected, the devuser1 currently has non-admin rights to the cluster, as indicated by the fact that the cluster administration section is now no longer available within the left-hand menu. Let's now go ahead and update devuser1 and give this user cluster admin permissions. 

Jumping over to the runsheet, under step eight, copy the add cluster role to user command. Then I'll execute it within the terminal. This command assigns the cluster admin role to devuser1. Next, I'll use the following oc command to re-authenticate the devuser1. Again, this login has been successful, but this time I now have access to more projects, in fact, 51 of them. This is a direct result of the upgraded cluster admin privileges that devuser1 now has. 

The remaining step eight commands are executed to query the user that the oc utility is now operating as, and whether it indeed has cluster admin permissions. If it didn't, the oc get scc command would fail, which it hasn't, as indicated by fact that a list is returned. So our credential and permission management looks good for devuser1. Having confirmed all this, we can jump back into the runsheet and copy the last command within step eight and execute it within the terminal to remove the temporary kubeadmin credential. 

Okay, that completes step eight, we're now in good shape and ready to start rolling out the resources required to deploy our working sample Voting App cloud native application.