EKS Anywhere, SSO with KeyCloak OIDC

This article is part of the EKS Anywhere series EKS Anywhere., extending the Hybrid cloud momentum

Motivation for this article. OIDC based authentication for Kubernetes is a very important consideration for obvious security reasons. As such, there is no complete example of EKS Anywhere with OIDC authentication beyond one snippet in the official documentation.

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 are using the typical method of cert-manager plus LetsEncrypt., in which case your KeyCloak server needs to be accessible from the internet (due to certificate validation methods used by LetsEncrypt) OR
• You have direct access from your machine that runs a browser to the target Kubernetes cluster

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. 
• Lastly, I wanted to perform kubectl authentication via Browserless OIDC method since I am logged into a remote linux server

What are we going to achieve

We will be deploying a simple KeyCloak server as the IdP provider with OIDC support. In addition to supporting other applications, this KeyCloak server will render an OIDC client that will perform EKS Anywhere cluster authentication.

Note that we will be deploying other applications in this saga series that will also use the same KeyCloak server and OIDC client being setup herein.

The below visual represents the overall workflow of how we will be authenticating into our EKS Anywhere cluster using a combination of KeyCloak and Kubernetes RBAC entities.

In a nutshell, based on the RBAC policies defined within our EKS Anywhere cluster/s, users will be authenticated to perform various operations. 

In this example, we will configure KeyCloak as an OIDC provider for all the EKS Anywhere clusters (management and workload).

• The KeyCloak server will be running as a docker container on our EKS Administrative machine itself.
• In addition to being an OIDC provider for our EKS Anywhere clusters, the KeyCloak server will also be leveraged for OIDC based SSO towards other use cases (GitLab, Portainer, ArgoCD, Kubeapps, etc.)
• Next, we will setup the RBAC on the EKS Anywhere clusters to map the OIDC groups for respective permissions.
• The Kubernetes and KeyCloak RBAC mappings are seen in the above flow diagram
• Lastly, we will simulate the OIDC user access via Browserless contexts
• user-admin has a cluster-wide admin role and can define namespaces, etc.
• user-dev cluster-wide edit role and as an example cannot define namespaces, however, can create deployments, etc.
• user-view-only cannot create any resource and cannot view nodes, etc., however can view the other resources as per the standard role of “edit”

Some of the examples that I have used in this saga series leverage "ambarhassani" as the SSO user id. In the terraform templates, you will not observe the configuration for this user. However, adding a user to define an additional user is a very simple step by login into the KeyCloak web console.

Prerequisites

Your EKS Anywhere Administrative machine is setup via Terraform procedure as per this article

IMPORTANT NOTE:

Do not switch the ubuntu user to root on EKSA Administrative machine while performing the below procedures. Terraform and Homebrew are installed via ubuntu Linux user. If you switch to root, it will cause permission issues. while creating the KeyCloak server via the Terraform configurations.

What to do next? In summary, you can return to the saga series and reference the sequential blogs in the OIDC section. Those articles will help you build the KeyCloak server and validate the OIDC workflows with EKS Anywhere clusters.

cheers

Ambar Hassani

#iwork4dell