18 May, 2020 | 3 min read

Deploying WSO2 Identity Server in Kubernetes

  • Ajanthan Balachandiran
  • Software Engineer - Wso2 Inc.

Image credits: Jesus Kiteque on Unsplash

In this post, I am going to give a brief introduction to deploying WSO2 Identity Server on Kubernetes. If you are going to deploy on a Kubernetes cluster, WSO2 has detailed documentation on the process. A basic understanding of Kubernetes is needed to follow this guide. There are plenty of resources out there to get a basic understanding of Kubernetes, even the official documentation is good enough.

For any deployment on proper multi-node Kubernetes setup on either big clouds (AWS, Azure, and GCP) or on-premise or even bare metal I would recommend this guide. If you want to deploy locally on a Mini Kube environment, unfortunately, the above resource doesn’t work without a few modifications. In this post, I'll provide guidance on deploying WSO2 Identity Server on Mini Kube using the above resource as a basis with some modifications.

Installing Mini Kube

As a first step, make sure you have the Mini Kube setup with enough memory and CPU allocated. I would say having 4 CPUs and 8 GB memory is more than enough for this deployment.

Installing Ingress Controller

An ingress controller is needed to access WSO2 Identity Server from the browser. Setting up an Ingress controller with SSL passthrough is simpler than doing an SSL termination. This is the approach mentioned in the official guide from WSO2. The ingress controller add on of Mini Kube doesn’t support the SSL passthrough. We have to deploy the modified Kubernetes manifest to deploy an ingress controller with SSL passthrough instead of the add on. I have a Github repository with the required manifests. Clone the repository and copy the manifests to ~/.minikube/addons location and restart the Mini Kube.

git clone
cd minikube-ingress-with-ssl-passthrough
cp *.yaml ~/.minikube/addons
minikube stop
minikube start

Installing WSO2 Identity Server

Updating configurations

Clone the WSO2 Kubernetes resource git repository locally. We are going to modify it to fit Mini Kube. If you want to skip modifying the configurations and head straight into deploying, I have an updated repository with all the changes. You can use it and deploy Mysql and WSO2 Identity Server without going through the following steps.

git clone

Persistence volume is used to store and data generated by Mysql POD and WSO2 Identity Server POD. By default, NFS is used as a persistence volume provider. For Mini Kube based local setup, setting the Hostpath persistence volume type will simplify the deployment process since it doesn't require any NFS. It will just mount a folder from the host machine. To enable Hostpath persistence volume type for WSO2 Identity Server persistence volume configuration and Mysql configuration, the following changes have to be done.

For Mysql:

For WSO2 Identity Server:

When the Hostpath volume persistence is used with Mini Kube, the container needs root access to access the attached volume since the Mini Kube VM doesn’t have any none root users. Creating a none user in Mini Kube VM is also not straightforward. To make things simpler here, we are going to run the WSO2 Identity Server container and the Mysql container as root. Running the containers as root in production is strictly not recommended but for demo purposes, we could run it. Do the following changes to run containers as the root user.

Mysql container:

WSO2 Identity Server container:

The default WSO2 Identity Server POD uses an image that requires a trial license from WSO2 because it has bugfix patches that are under a commercial license. In this exercise, we are going to use the open source version of the images from the official Docker hub.

For a single node demo deployment clustering is not needed. The official Kubernetes guide has clustering enabled. Let’s disable the cluster as follows.

Now we are ready to deploy the setup. We are going to deploy a single node WSO2 Identity Server without analytics on the default namespace. The official guide has a script to deploy or undeploy the setup but here we are going to use kubectl to deploy everything manually. I have committed the above changes to my own fork of the original repository. In the end, you should have the below changes to your checkout as in the commit history.

Deploying Mysql

Execute the following commands from the checkout directory to deploy persistent volume for Mysql.

kubectl create -f is/extras/rdbms/mysql/mysql-persistent-volume-claim.yaml
kubectl create -f is/extras/rdbms/volumes/persistent-volumes.yaml

A configMap with the script to populate WSO2 specific schema needs to be deployed.

kubectl create configmap mysql-dbscripts --from-file=is/extras/confs/rdbms/mysql/dbscripts/

Deploy Mysql deployment and the service to spin up the POD and expose it as service internally.

kubectl create -f is/extras/rdbms/mysql/mysql-deployment.yaml
kubectl create -f is/extras/rdbms/mysql/mysql-service.yaml

Wait for a few minutes and the Mysql POD will be up and running.

Deploying WSO2 Identity Server

The next step is deploying WSO2 Identity Server. First, deploy the volumes and create a service account.

kubectl create serviceaccount wso2svc-account
kubectl create -f is/volumes/persistent-volumes.yaml
kubectl create -f is/identity-server-volume-claims.yaml

Then apply the configMaps with all the customized configurations for Kubernetes.

kubectl create configmap identity-server-conf --from-file=is/confs/
kubectl create configmap identity-server-conf-axis2 --from-file=is/confs/axis2/
kubectl create configmap identity-server-conf-datasources --from-file=is/confs/datasources/
kubectl create configmap identity-server-conf-identity --from-file=is/confs/identity/

Then apply the deployment and the service for exposing WSO2 Identity Server for internal access.

kubectl create -f is/identity-server-deployment.yaml

Wait until the server is up and running. You may check the logs of the WSO2 Identity Server POD in order to determine whether the server is up and running.

kubectl logs  -f

Once the server is up and running you can deploy the service description and ingress controller.

kubectl create -f is/identity-server-service.yaml
kubectl create -f is/ingresses/identity-server-ingress.yaml

The final step of the deployment is updating DNS entry for the WSO2 Identity Server hostname. In order to get the IP address for the hostname, issue the following command and get the Mini Kube IP.

minikube ip

Then update your /etc/hosts entry with the following entry with the IP address you received in the previous step. wso2is

Now you can access the management console of WSO Identity Server on https://wso2is/carbon. In order to use the product, please use this getting started guide.

When you are ready to tear down the setup, issue the following commands in the order.

kubectl delete -f is/identity-server-volume-claims.yaml
kubectl delete -f is/volumes/persistent-volumes.yaml
kubectl delete -f is/identity-server-service.yaml
kubectl delete -f is/identity-server-deployment.yaml
kubectl delete -f is/extras/rdbms/mysql/mysql-service.yaml
kubectl delete -f is/extras/rdbms/mysql/mysql-deployment.yaml
kubectl delete -f is/extras/rdbms/mysql/mysql-persistent-volume-claim.yaml
kubectl delete -f is/extras/rdbms/volumes/persistent-volumes.yaml
kubectl delete -f is/ingresses/identity-server-ingress.yaml
kubectl delete serviceaccount wso2svc-account

In this guide, we have looked at how WSO2 Identity Server can be deployed in a Mini Kube environment. Learn more about WSO2 Identity Server here.