Deploy WSO2 Identity Server in GKE
Deploy WSO2 Identity Server in GKE
Learn more about how you can deploy the WSO2 Identity Server in GKE.
Join the DZone community and get the full member experience.Join For Free
WSO2 Identity Server is a full bloom product for identity management, provisioning, federation, etc. For more information on the product, please go to the official site. The WSO2 Identity Server (WSO2 IS) can be deployed either on-premise or in any cloud (AWS, Azure, Google, etc). In this article, we will go through each and every process to deploy the WSO2 IS in Google Kubernetes Engine.
Before We Start
We will need the following software in our system for the deployment.
- WSO2 Identity Server (version 5.7)
- Google Cloud Account (On first creation of a Google cloud account, you receive a $300 credit and that's enough for playing around)
Google Cloud provides Postgres and MySQL by default. But in this article, I am going to deploy PostgreSQL as a container and configure WSO2 IS to communicate with the PostgreSQL within the same cluster. Below are the necessary steps to make the deployment.
Generate Keystore for WSO2 IS
Below are the necessary steps to generate a self-signed certificate and subsequently create a keystore with the certificate.
1. Generate an RSA key
openssl genrsa -out wso2.key 2048
2. Generate a CSR. Put a valid CN or a * to allow any CN.
openssl req -new -key wso2.key -out wso2.csr -subj "/CN=*"
3. Generate the certificate
openssl x509 -req -days 7300 -in wso2.csr -signkey wso2.key -out wso2.crt
4. Generate PKCS12 file from the above key pair
openssl pkcs12 -export -in wso2.crt -inkey wso2.key -name wso2carbon -out wso2.pfx
5. Generate the keystore
keytool -importkeystore -srckeystore wso2.pfx -srcstoretype pkcs12 -destkeystore wso2carbon.jks -deststoretype JKS
Copy and replace the created wso2carbon.jks file inside the WSO2 identity server distribution under repository/resources/security.
1. Extract public certificate from the keystore.
keytool -export -alias wso2carbon -keystore wso2carbon.jks -file wso2.pem
2. Delete the existing WSO2 public certificate from the trust store. The default password is ‘wso2carbon.’
keytool -delete -alias wso2carbon -keystore client-truststore.jks
3. Add the new certificate to the client trust store.
keytool -import -alias wso2carbon -file wso2.pem -keystore client-truststore.jks -storepass wso2carbon
Create Docker Image for WSO2 IS
Below are the steps to build the Docker image:
- Download the artifacts from this GitHub location.
- Copy and paste the unzipped product under the following directory: is-postgres/is/docker/files
- Replace the <UNZIPPED_WSO2IS>/repository/conf/axis2/axis2.xml with the provided configuration file: is-postgres/is/configs/axis2.xml.
Note: We are not externalizing the axis2.xml configuration. Because when a volume is mounted using config map, it becomes immutable, i.e. no further modifications are allowed on that volume (axis2.xml in this case). But while doing a k8s clustering of
IdentityServer, it's necessary to update the
localMemberHostvalue of the axis2.xml with the Docker container IP. It's done via init.sh script. For this reason, the axis2.xml is not externally configured using contig map.
- Copy the postgresql-*.jar driver to the 'files' directory (already included the latest driver in the ‘files’ directory).
- Build the image using the running command under the directory is-postgres/is/docker.
docker build -t wso2is .
Push Docker Image to Google Container Registry
In the previous step, we created the WSO2 IS Docker image and it's available in the local registry. To make it usable inside the GKE, we need to push it to Google Container Registry (GCR). Below are the steps:
- Tag the image with the following format: gcr.io/<PROJECT_NAME>/<IMAGE>
PROJECT_NAME: It's the name of the project created in GCP.
docker tag wso2is gcr.io/wso2-is-17/wso2is
- Push the image to Docker registry
docker push gcr.io/wso2-is-17/wso2is
Docker Image for PostgreSQL
Follow the below steps.
- Pull official Postgres image from Docker hub.
- Tag the Docker image with the following format gcr.io/<PROJECT_NAME>/<IMAGE>
docker tag postgres gcr.io/wso2-is-17/postgres
- Push the image to Docker registry:
docker push gcr.io/wso2-is-17/postgres
At this point, our Docker images are pushed to Google's Container Registry and you can view them as shown:
Please follow the steps in the given order to deploy the whole stack of WSO2 Identity Server and PostgreSQL.
Setting Project and Timezone
Enable the following settings in the Google Cloud console.
gcloud config set project wso2-is-17 gcloud config set compute/zone us-central1-a #Your prefered TZ
Create a cluster using the following command in the cloud console:
gcloud container clusters create wso2-is --enable-ip-alias
Here is an example of the cluster:
Create a namespace and select it:
kubectl create ns wso2 kubectl config set-context $(kubectl config current-context) --namespace=wso2
Create a Service Account
Next, create the service account and provide permission to communicate with the K8s API. This service account is required by the WSO2 servers to communicate with the K8s APIs.
Before proceeding with account creation and permission assignment, make sure the logged in user has the cluster-admin role. To assign the cluster-admin role to the current user, use the following command.
kubectl create clusterrolebinding cluster-admin-binding --clusterrole cluster-admin --user $(gcloud config get-value core/account)
Next, create the service account and assign permission for the service account.
kubectl create serviceaccount wso2svc-account kubectl apply -f ./is/kube/is-rbac.yaml
Deployment of Postgre
Create the following config map:
is-postgres>kubectl create configmap init-data --from-file=./postgres/scripts
is-postgres>kubectl apply -f ./postgres/kube/postgres-deployment.yaml
is-postgres>kubectl apply -f ./postgres/kube/postgres-service.yaml
Deployment of WSO2 Identity Server
Create the following config maps:
is-postgres>kubectl create configmap config-datasource --from-file=./is/configs/master-datasources.xml is-postgres>kubectl create configmap config-usermgt --from-file=./is/configs/user-mgt.xml is-postgres>kubectl create configmap config-identity --from-file=./is/configs/identity.xml is-postgres>kubectl create configmap config-ldap --from-file=./is/configs/embedded-ldap.xml
Session affinity should be maintained when the fronting a multi-node WSO2 IS cluster with an LB. This is mainly required for the management console as the logged in the session of the management console is kept in memory and not shared between the nodes.
Session affinity is configured for the ingress through a BackendConfig kubernetes resource and the session affinity is maintained using a generated cookie. The following snippet should be added to set up a cookie-based session affinity with an expiry period of 1 day (86400 seconds).
Create the backend config:
kubectl apply -f ./is/kube/is-backendconfig.yaml
Create the service:
kubectl apply -f ./is/kube/is-service.yaml
Create the deployment:
kubectl apply -f ./is/kube/is-deployment.yaml
Create the ingress:
Before creating the ingress, we need to provide a certificate for it. For this demo, we can use our self-signed certificate to create a TLS secret named as is-cert:
kubectl create secret tls is-cert --cert wso2.crt --key wso2.key
Next, create the ingress:
kubectl create -f ./is/kube/is-ingress.yaml
Note: Don't forget to create a host in your /etc/hosts file for the ingress i.e wso2is.app!
In this article, I have shown a demo of WSO2 IS deployment in GKE. This is a very simple deployment without any rules (e.g. limiting access to internal and external users). This can be done in the ingress itself defining two hosts and applying rules. Also, IP-whitelist/blacklist can be applied in the BackendConfig using policies. In the next articles, I will try to cover them, so stay tuned.
Opinions expressed by DZone contributors are their own.