Unsolved
1 Message
2
2949
OpenShift, SSO with KeyCloak & Active Directory
Motivation for this article. There is no easy-to-follow example of using Keycloak OpenID Connect (OIDC) authentication with OpenShift using Active Directory as a user federation source.
In addition, most of the internet examples for OIDC assume that either;
- The KeyCloak OIDC server certificate is signed by an external well known Certificate Authority OR.,
- You already know how to extract a cert from the Keycloak server and construct the ca.crt file in the appropriate format for OpenShift to interpret.
In my case, the KeyCloak server is a private entity and is not exposed to the Internet. In addition, I will be using a self-signed certificate as the KeyCloak server is internal and accessible via private IP. Therefore, I had to resort to a method that works with these constraints in place.
What are we going to achieve?
OpenShift OAuth workflow with KeyCloak OIDC and Active Directory user federation;
- In this example, we will configure KeyCloak as an OIDC provider for the OpenShift cluster provided
- The KeyCloak server will be running as a pod on our OpenShift cluster in a dedicated project
- Once the KeyCloak server is up, we will create a new realm and a client config for the OpenShift cluster
- Next, we will configure Active Directory user federation with read-only access to allow AD domain users to login to the OpenShift cluster via the Keycloak IDP
- We will then setup a new OAuth identity provider on the OpenShift cluster to connect to the Keycloak server as defined in the client config above
- Lastly, we will setup the RBAC permissions on the OpenShift cluster to create a new group and role binding to map specific users to the cluster admin role
Prerequisites
Your OpenShift cluster is setup and ready. Ensure that the appropriate install procedure from RedHat has been completed as per your preferred platform and version; https://docs.openshift.com/container-platform/4.10/installing/index.html
You have a wildcard FQDN entry in your DNS server for the OpenShift cluster that maps to the IP address of the Ingress VIP that your applications and Keycloak server will use.
*.apps.
.
x.x.x.x Example; *.apps.cluster-01.lab.local 192.168.112.177
The standalone or single node cluster deployment model will also work just fine. However, for this article and demo environment we have used a 3-node cluster deployment with both master and worker nodes schedulable.
In summary, you can perform the below actions on a Linux machine that has the openshift-install binary and access to a vCenter server if using IPI in a vSphere environment;
Create the following DNS entries
api.
.
x.x.x.x *.apps.
.
x.x.x.x Download and extract the vCenter certs - https://
/certs/downloads.zip cp certs/lin/* /etc/pki/ca-trust/source/anchors update-ca-trust extract Create the installation directory and config templates mkdir
./openshift-install create install-config --dir
? Platform vsphere ? vCenter
? Username administrator@vsphere.local ? Password [? for help] ************* ? Cluster
? Default Datastore
? Virtual IP Address for API
? Virtual IP Address for Ingress
? Base Domain
? Cluster Name
? Pull Secret [? for help]
Edit the install config file only if you want to deploy a 3 node cluster (default will deploy 3 x master + 3 worker nodes) cd
vi install-config.yaml #### edit the worker node #### replicas: 0 ../openshift-install create manifests Note: WARNING Making control-plane schedulable by setting MastersSchedulable to true for Scheduler cluster settings Start the cluster deployment (total build time approx. 20-30mins) cd .. ./openshift-install create cluster --dir
--log-level=info
Once the cluster is deployed and completed successfully, you can use the kubeconfig file created to authenticate and login to the cluster via the kubectl cli tool
export KUBECONFIG=~/
/auth/kubeconfig kubectl get nodes
In addition, we will use the oc tool provided by RedHat to perform cli based actions on the cluster. Please download the oc toolset and install as appropriate (e.g. https://mirror.openshift.com/pub/openshift-v4/x86_64/clients/ocp/stable/openshift-client-linux.tar.gz)
oc login
You must obtain an API token by visiting https://oauth-openshift.apps.
.
/oauth/token/request Use the kubeadmin password provided at the completion of the cluster deployment to login and retrieve the token "kubeadmin", and password: "xxxxx-xxxxx-xxxxx-xxxxx" Display token and copy the full command to login to the cluster oc login --token=sha256~xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx --server=https://api.
.
:6443 oc get nodes
We are now ready to proceed with the KeyCloak server deployment and setup.
Step-1 Deploying the KeyCloak server pod
We will utilize the oc tool to create a new project and deploy the Keycloak server from a github repository as documented in the following guide (https://www.keycloak.org/getting-started/getting-started-openshift)
oc new-project keycloak
oc process -f https://raw.githubusercontent.com/keycloak/keycloak-quickstarts/latest/openshift-examples/keycloak.yaml \
-p KEYCLOAK_ADMIN=admin \
-p KEYCLOAK_ADMIN_PASSWORD=admin \
-p NAMESPACE=keycloak \
| oc create -f –
You should see the below output
service/keycloak created
route.route.openshift.io/keycloak created
deploymentconfig.apps.openshift.io/keycloak created
Wait a few minutes and check that the pod is created and running
oc get pods
You should see a status similar to the below
NAME READY STATUS RESTARTS AGE
keycloak-1-deploy 0/1 Completed 0 1m
keycloak-1-l9kdx 1/1 Running 0 1m
Run the below command to extract the URL’s for the Keycloak admin and account consoles
KEYCLOAK_URL=https://$(oc get route keycloak --template='{
{ .spec.host }}') &&
echo "" &&
echo "Keycloak: $KEYCLOAK_URL" &&
echo "Keycloak Admin Console: $KEYCLOAK_URL/admin" &&
echo "Keycloak Account Console: $KEYCLOAK_URL/realms/myrealm/account" &&
echo ""
Step-2 Creating the realm and client on KeyCloak server
You can browse the FQDN of the KeyCloak admin console and login to the administration console with the URL retrieved in the previous step and the following credentials;
https://keycloak-keycloak.apps. . /admin
username: admin
password: admin
Upon successful login, you can change the admin password by navigating to the ‘account management’ console using the link in the top right of the screen.
Once redirected to the account management console, click on the ‘Signing in’ link found in the Account Security section
And update your password with a new password
You can then navigate back to the admin console using the link in the top right of the screen
We will now create a new realm by hovering over the Master dropdown in the top-left and clicking the ‘Add realm’ button
Provide a name for the realm and ensure the enable button is on before clicking the ‘create’ button
Next we will create a new client that will be used by our OpenShift cluster.
Navigate to the ‘Clients’ tab using the left menu and click on the ‘Create’ button on the top right of the Clients page
Provide a ‘Client ID’ and take note of the exact name as we will need this later in our OpenShift OAuth configuration.
Select the ‘openid-connect’ protocol and leave the Root URL blank before clicking ‘Save’
After saving the client, you will see more options that can be entered
Leave the defaults, except for the following;
- Access Type: confidential
- Valid Redirect URIs: https://oauth-openshift.apps. . /oauth2callback/keycloak
Save the settings before proceeding
Do not create any users or groups as we will be using user accounts from Active Directory and Group / RBAC roles will be defined in the OpenShift cluster later in the article.
Step-3 Setup an ldap User Federation provider to connect Keycloak with Active Directory
Prerequisites
Before beginning this step, you must have the following details retrieved from your Active Directory server;
- A user account to bind the Keycloak server with the domain
(this can be a service account or any user that already exists. E.g. administrator) - A valid bind DN for the service account. Can be retrieved by running the following command on the AD controller
- dsquery user -name
- A valid users DN that is usually the default Users folder unless a specific setup is implemented
Example of default users DN;
CN=Users,DC=lab,DC=local
Once you have collected the above information, you can proceed as follows
Navigate to the User Federation page and add a new ldap provider as shown below;
Ensure the ‘Enabled’ and ‘Import Users’ toggles are set to “ON”
Select the ‘Edit Mode’ as “READ_ONLY”
Select the ‘Active Directory’ vendor from the dropdown list
Enter the connection URL as ldap://
Then enter the Users DN, Bind DN and Bind Credentials into the fields and test the connection and authentication to ensure you have them correct
All other fields can be left as defaults, then save when complete
Step-4 Configure OAuth settings on the OpenShift cluster
The OAuth configuration is specific to the client that was configured in the Keycloak server. If you want to add another cluster, repeat step 2 and create a new client for each OpenShift cluster.
We now need to retrieve the SSL cert from the Keycloak server as we will be importing this certificate into the OpenShift cluster as a trusted certificate.
From a Linux host, run the following command;
echo | openssl s_client -showcerts -connect keycloak-keycloak.apps.
.
:443 2>&1 | sed --quiet '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > keycloak.crt
The above command will generate a file called keycloak.crt that contains the certificate chain for the Keycloak self-signed certificate.
Download this file to your desktop as we will use this to upload into OpenShift via the web console.
Login to the OpenShift console using the URL provided by the installer during deployment and the kubeadmin username / password
(e.g. https://console-openshift-console.apps. . )
Once logged into the console, navigate to the ‘Administration’ -> ‘Cluster Settings’ page and go to the ‘Configuration’ tab
Scroll down and click on the OAuth link
You should now see the option to add a new Identity provider by selecting the dropdown at the bottom of the screen
Click the dropdown and select OpenID Connect
Now we need to obtain the ‘secret’ credential from the Keycloak client we created earlier. Login to Keycloak admin console and find the credentials tab in the configuration of the client.
Copy the secret string and paste it into the OpenShift OAuth config under ‘client secret’.
Enter the name of the IDP as ‘keycloak’ and provide the same client ID as configured in Keycloak server.
Provide the Issuer URL as;
https:// /realms/
Lastly, click the browse button and upload the keycloak.crt file with the certificate we extracted in the previous step and click the ‘Add’ button.
Step-5 Configure RBAC on the OpenShift cluster to provide specific users with Cluster Admin privileges
Now that we have our OAuth Identity Provider configured and Keycloak federating with Active Directory, we need to establish how a user can be provided with different RBAC roles and permissions.
In this example, we will create a group and assign a role-binding to the Cluster Admin role. Then we can add users to the group and they will inherit the role of Cluster Admin. RBAC can be implemented in many different ways, but this is a simple example for an initial POC that demonstrates the OIDC implementation leveraging AD users and OpenShift controlled RBAC.
In the OpenShift console, navigate to ‘User Management’ -> ‘Groups’
Click on ‘Create Group’ and populate the yaml definition with a group name and the Active Directory user accounts you want to give ‘Cluster Admin’ access to
Create the group, then go into the config and navigate to the ‘RoleBindings’ tab
Create a new binding, select ‘Cluster-wide role binding’ and provide a name, then select the ‘cluster-admin’ role from the Role name dropdown
Final step - testing
At this stage, all the configurations are complete with a perfect segue to testing our user access with the respective permissions. We will do so by logging in with an AD user that has not been added to the ‘cluster-admins’ group and a user that has been included in the group to contrast the different access permissions.
First, log out of the console and reload the console page to confirm the new IDP is available as shown below;
Click on the ‘keycloak’ button to login with an AD user.
We will use the test_user in this example as a standard user with no additional permissions.
You will notice after logging in that the user is provided with no access to any existing projects or administrator functions such as cluster wide configurations
Now, logout of that user and login with another user that was added to the ‘cluster-admins’ group.
You should notice the difference immediately and the cluster admin user will have full cluster wide priviledges.
This brings us to the end of the article and our implementation of OIDC SSO with Keycloak and Active Directory. I hope you enjoyed the demonstration and found this useful in your own deployments of POC’s, Lab’s and Production environments.
Take care
Theo