Authentication

This section will cover running authentication tools inside your cluster. In particular, we will be focusing on the use of Keycloak to act as an OIDC provider. This provider can then be used to authenticate your internal tools running within Kubernetes as well as outside Kubernetes (as long as it is inside the same VPC).

Most organization have their own VPN which can be used to access resources within their private VPC. This is standard practice when managing your internal resources since you want to minimize your attack surface as much as possible. This means severely reducing the amount of internet-facing services you have that can be susceptible to vulnerabilities. So while well-established providers such as Google SSO exist, your services need to be internet-facing for those providers to work. This is where running your OIDC provider within your VPC comes in handy. If both your provider and the tools that use the provider are in the same VPC, there is no issue.

For this example, we will be setting up Keycloak, and then using it to authenticate Devtron, which is a CI/CD & cluster operations tool. To learn more about it, head to the observability section. We will set up both tools with Helm, which you are already familiar with. You will also need to have a Kubernetes cluster either running locally on your machine or on a cloud platform.

Keycloak installation

Bitnami has an official Keycloak chart present, but this chart has some unresolved issues around its database configuration, so we will be using a different Keycloak chart from codecentric instead. We will be using all the default values since they work fine for our use case, so install the chart with the following:

helm install keycloak codecentric/keycloak

Once the pods are ready, you can use port forwarding to access the Keycloak dashboard:

kubectl port-forward svc/keycloak-http 80:80 -n keycloak

You could also use a load balancer to access the resource by editing the service and setting the type to load balancer. Make sure you also set the annotation:

service.beta.kubernetes.io/aws-load-balancer-internal: true

This will make sure your LB is internal instead of internet-facing.

Devtron installation

Now that Keycloak is up, let’s focus on setting up Devtron. We will set it up without any additional integrations:

helm repo add devtron https://helm.devtron.ai
helm repo update devtron
helm install devtron devtron/devtron-operator \
--create-namespace --namespace devtroncd

Exposing this is similar to exposing Keycloak. Either use port forwarding or edit the devtron-service inside the devtroncd namespace the same way as before. Once you have done that, log in to the Keycloak dashboard.

Managing the realm

Keycloak allows you to separate your clients into various realms. For this exercise, you can use the default master realm used by Keycloak, or you could create your own realm to put the clients under. In any case, all you need to do here is to go to Realm settings > General, and click on “OpenID Endpoint Configuration”. This will open up a JSON page. Take note of the first item in the block issuer. You will need this for the next part.

Creating the Devtron client

Since Keycloak is the provider, Devtron will be the client that requests the authentication service. In the same way, if you had a different service that required authentication with Keycloak, that would be another client.

From the left pane, go to clients > Create.

Here, set the client ID to devtron, and the name to Devtron. Make sure the client protocol is openid-connect and the access type is confidential. Under “Valid Redirect URIs”, you will set the redirect URL you get from Devtron in the next step. You will use the same URL for “logout redirect URIs” and “web origins”. Save the client and head to the credentials tab at the top of the page where you can get the client secret.

Setting up Devtron to use Keycloak

Start up Devtron and log in as admin. Go to Global Configurations → SSO Login Services → OIDC. There will be a callback URL generated by Devtron (/api/dex/callback), we will be using this to redirect the URL of Keycloak that was mentioned in the previous step. In the config itself, set everything as follows:

Set issuer to the issuer URL you got from the previous step. Set clientID to devtron. Set clientSecret to the client secret from the previous step. Set redirectURL to the callback URL.

With that, you are done setting up auth from both the Devtron and Keycloak side. Now, it’s time to create users.

Creating users

Keycloak

First, you will create users from Keycloak and assign them to the Devtron client. These are SSO users which you can use for other clients as well. For example, if you were also setting up SSO for ArgoCD, the users you create here would be able to log in to both Devtron & ArgoCD using the same account (provided you have given them those permissions). Creating a user is very simple, just head over to the user’s section from the left pane, add a Username, email, and Name, and create the user. Next, go to the credentials tab and assign a user a new password, then select the change password option. This will make sure that the user has to use the password you give to log in for the first time, after which they are forced to change their password before they can go any further. You can also create user groups and assign users to them, which is useful if you are controlling users at an RBAC level. But since Devtron provides its own role-based auth, you can skip that.

Devtron

Once the user is created from Keycloak, take the user’s email and head over to Devtron. Go to the user management section and create a user from the Devtron UI. Here, make sure to set the email to exactly the same one you took from Keycloak. There is no additional configuration needed from the users’ end here since Devtron will match the user using the email and get the rest of the required information.

Creating roles

Now, set the user roles and permissions. In Devtron, you can create permission groups and specify granularly what kind of access each user has to each Kubernetes resource. Once you have assigned all the permissions your user will need, assign the permission group to the user. You can assign multiple permission groups to each user, increasing their level of access with each one, or you could directly give super admin privileges.   In tools like ArgoCD, you must create Kubernetes roles, assign permission to these roles, and then assign these roles to individual users. Or you could create a user group in Keycloak, add Keycloak users to these user groups, and then assign roles to these user groups instead of individual users. You can read more about cluster roles and role bindings in the RBAC section

This is all you need to do to set up OIDC auth with Keycloak. Now, when users come to your Devtron page, they will see an option to “log in with OIDC.” Selecting this option will redirect them to the Keycloak login page, which allows them to log in. Any other tools configured with Keycloak will have the same auth flow.

Conclusion

There are a lot more features available in Keycloak besides just creating users and user groups. Consult their official documentation if you need these features. Here, we just used the basic set of the properties required to set up OIDC with Keycloak for Devtron in the simplest manner possible, all without exposing a single service outside your VPC of added security and compliance measures.