Play around with Keycloak in k8s

A DevOps team may be accessing multiple applications and tools in a single product environment in support of their DevOps processes such as CI/CD server, Centralized log, Kubernetes dashboard, Monitoring software, Artifact repositories, Admin tools, etc. All of these tools will require authentication mechanisms for security purposes, and for a user to maintain and remember their authentication credentials on so many softwares can quickly become cumbersome. And in the event of lost credentials, it can be a tedious process for both user and admins to recover the required credentials.

Instead of having individual authentication on various tools, a more effective strategy is to use single sign-on for all tools, i.e. a centralized authentication mechanism that can allow or reject access to a set of tools based on a single set of credentials per user. Additionally some tools may not have authentication built into them at all, and may be reliant on an external authentication server in any case. An external authentication server with single sign-on capability can therefore prove to be the way to go in such a situation.

Single Sign-On

Single Sign-On (SSO) allows users to log in using a single set of credentials, e.g. username and password, so they can easily access a set of applications. SSO. SSO saves time and energy for users because they do not have to repeatedly log into multiple applications. This provides a smooth user experience, and makes it less likely to have access problems because of lost or forgotten credentials, locked out accounts, etc.

Keycloak

Keycloak is an Open Source Identity and Access Management solution. It provides an easy way to add authentication including Single Sign-on to applications and services with minimum effort. Keycloak handles persistence and user authentication all out of the box.

Instead of having to login to individual applications, users authenticate with Keycloak rather than individual applications. This means that the individual applications don't have to implement their own login forms, authentication, and storage of users and sessions. Once logged-in to Keycloak, users don't have to login again to access a different application. And similarly once logged-out from Keycloak, users don't have to log out of individual applications. Enabling login with social networks is also easy. The configuration for these can be added via Keycloak's admin console. No code or changes are required to individual application

Keycloak supports OpenID Connect and SAML protocols. OpenID Connect (OIDC) is an extension of the OAuth 2 authentication protocol. While OAuth 2.0 is a framework for building authorization protocols, and OIDC is the full implementation of a authentication and authorization protocol. SAML 2.0 is similar to OIDC but a lot older and consequently more mature. It has its roots in SOAP and works by exchanging XML documents between the authentication server and the application, so it tends to be a bit more verbose than OIDC. In most cases OIDC is recommended by Keycloak.

Keycloak Gatekeeper

Keycloak Gatekeeper is an adapter which integrates with the Keycloak authentication service. We deploy it on a per-application instance basis. So usually this will be a sidecar container deployed with the application container on the kubernetes pod. We configure the kubernetes service of the application so that it points to the gatekeeper rather than the application itself, so that the gatekeeper can act as a proxy for incoming requests. The gatekeeper then verifies from the Keycloak server if an active authenticated session exists or not. If not, it redirects the client to the Keycloak login page. If the session exists, it allows the incoming request to pass through to the application container.

Using the Keycloak Gatekeeper allows us to have zero authentication configuration within the application itself. The session verification, redirection to Keycloak in case of an invalid session, and pass through to the application in case of a valid session, are all handled by the gatekeeper.

Stakater Proxy Injector

Deploying a sidecar container for Keycloak Gatekeeper with all our applications can be a hassle. So we want to automatically inject a keycloak gatekeeper container in a pod, for any deployment that requires to connect to keycloak, instead of manually adding a sidecar container with each deployment. This Proxy Injector controller will continuously watch deployments in specific or all namespaces, and automatically add a sidecar container for keycloak gatekeeper. Configuration for the keycloak gatekeeper is done through annotations of the respective deployment or with ConfigMap of the ProxyInjector.

Steps in Kubernetes cluster with Traefik

Keycloak chart

Install Keycloak chart by helm

helm repo add codecentric https://codecentric.github.io/helm-charts
helm install --name keycloak codecentric/keycloak
# helm list
# helm delete <name> (delete the chart)

Remember the username and password from the result.

Traefik ingress

Create the keycloak ingress yaml to expose the keycloak web, and specify the sub-domain for it

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: keycloak-ingress
  namespace: jx
spec:
  rules:
    - host: <sub-domain>
      http:
        paths:
          - path: /
            backend:
              serviceName: keycloak-http
              servicePort: 80

Open the exposed url

Enter the administration console and use the previous username and password to login.

Create a user and specify the username and reset the password to set the user password to the new one you specified.

Create a client which is the application you want to inject authentication in front of.

Modify the access type to the confidential and save.

Create a client scope.

Click the Mappers and create a mapper with the Audience type.

Enter the new client and click the Client Scopes, move the available new scope to selected.

You can add a realm other than Master Realm at any time.