Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Deploy WSO2 Identity Server in GKE

DZone 's Guide to

Deploy WSO2 Identity Server in GKE

Learn more about how you can deploy the WSO2 Identity Server in GKE.

· Security Zone ·
Free Resource

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)
  • Docker
  • 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 localMemberHost value 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:

Image title

Deployment

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 Cluster

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:Image title

Create Namespace

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


Create deployment:

is-postgres>kubectl apply -f ./postgres/kube/postgres-deployment.yaml


Create service:

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

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!

Conclusion

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.

Topics:
mule 3.8 ,gke ,google cloud ,security ,cybersecurity ,keystore ,trust ,postgresql ,docker ,docker image

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}