Extend SSB (Standard Service Build) to Containerize IdentityIQ

[#1]

• Background
• Summary
• Build IdentityIQ docker Image
• Deploy IdentityIQ to Docker Container Instance
• Deploy IdentityIQ to Kubernetes
• References

Background

Containerization is becoming extremely popular now days due to high adoption of cloud technologies across all industries. Many customers even have such IT strategic policy which dictates that all new applications must be running in a containerized cloud environment. IdentityIQ doesn't natively support container but it can be running in a container with some extra configuration. This document describe the solution which allows you to containerize the IdentityIQ application without losing the best practices (such as SSB a.k.a Standard Service Build) that have been widely used in many projects.  

Summary

The solution is built on top of SSB (Standard Service Build) v7.0.1. It relies on SSB to perform the build the IdentityIQ war file. The war file is then used to build a Docker container image. The generated Docker image can then be deployed to a Kubernetes cluster or Docker container instance..  The containerized IdentityIQ runs in Tomcat 9.0.72 and JDK 11.

The solution includes 2 parts:

• Build IdentityIQ docker image
• Deploy IdentityIQ docker image to Kubernetes cluster

Build IdentityIQ docker Image

Refer to the following github repository for more details about how to build a docker image for IdentityIQ

https://github.com/renliangfeng/iiq-container

Deploy IdentityIQ to Docker Container Instance

To run IdentityIQ in a Docker Container instance is simply to execute the following command after the docker image is built. Before that, you need to prepare the iiq.properties file and save it in your preferred location, then update the command with the right path. Most likely, you may want to override log4j2.properties with your ownn version. You can just simply add an additional parameter. Lastly, change "iiq-image" to name of docker image you've built.

docker run -it -v /Users/bruce.ren/Desktop/log/sp-log/:/usr/local/tomcat/logs -v /Users/bruce.ren/Desktop/iiq-properties/sandbox/iiq.properties/:/usr/local/tomcat/webapps/identityiq/WEB-INF/classes/iiq.properties --name my-iiq-container -d -p 8080:8080 iiq-image

Deploy IdentityIQ to Kubernetes

Docker Desktop includes a standalone Kubernetes server and client, as well as Docker CLI integration that runs on your machine. The Kubernetes server runs locally within your Docker instance, is not configurable, and is a single-node cluster. This is a perfect way to develop and unit test a Kubernetes/Docker solution. This document focus on steps to deploy IdentityIQ (containerized docker image) to the single-node cluster in local Docker instance. However, with some modification, the Helm Chart can be enhanced to support the production-grade Kubernetes cloud service (e.g. AWS EKS or Azure AKS). 

Below diagram shows the high level deployment process in a AWS EKS environment.

Refer to the following github repository for more details about the process:

https://github.com/renliangfeng/iiq-chart

References

https://www.docker.com/products/docker-desktop/

https://kubernetes.io/

https://helm.sh/ 

https://community.sailpoint.com/t5/Professional-Services/Services-Standard-Build-SSB-v7-0-1/ta-p/190...

[alanz]

Hi, 

We are currently discussing a new implementation of Sailpoint IIQ running on KS8. We also found the post below:

https://community.sailpoint.com/t5/Technical-White-Papers/Best-Practices-Containerized-IdentityIQ-De...

1. IdentityIQ Architecture and Server Lifecycle: Container environments must meet all IdentityIQ requirements, including the operating system version, JVM version, and others. The increased frequency of server lifecycle events due to containerisation needs to be efficiently managed.

2. IdentityIQ Process Resiliency: IdentityIQ's resiliency features, such as Process Resiliency and Environment Monitoring, should be properly leveraged in a containerised deployment to allow IdentityIQ to recover appropriately from server downtime.

3. Server Hostnames: There's a challenge in choosing between predefined hostnames and dynamically defined hostnames. Predefined hostnames limit container replication, while dynamically defined hostnames require additional scripting and cannot be statically defined in IdentityIQ.

4. IQService and Connector Gateway: These components are not recommended for containerisation due to networking and security issues. They need to be hosted separately, introducing complexity in managing a mixed environment.

5. File System Resources: Designing a strategy for persistent storage that survives container deprovisioning is necessary. This includes handling resources such as file resources for IdentityIQ applications, log files, full text indexes, and keystores.

6. Serverless Computing with Containers: If you are choosing a serverless environment, there are limitations, such as limited container feature support and potential performance degradation, which must be taken into account.

7. SailPoint's Support Limitations: SailPoint supports IdentityIQ deployed in a container, but not the container or the containerization process itself. Any issues related to containerization fall outside SailPoint's support scope.

Based on the challenges and facts above, how viable is to actually containerise Sailpoint IIQ 8.3 from your perspective? 

[bruce_ren]

hi @alanz , this IIQ/Kubernetes solution is based on a real scenario project that I am currently working on. The project is still in development phase but it will go live soon. So from what I can see, it's viable even though we have faced a few challenges but eventually we found solutions to overcome. 

[alanz]

@bruce_ren that is great to hear. Our organisation prefers containers over dedicated infrastructure. However, when evaluating we found the post above we felt a little bit discouraged but from your post seems that even the challenges can be overcome with the right experience. 

Would you be able to tell what sort of challenges did you face? Are they listed on my first message? 

Did you get approval from Sailpoint in terms of the solution design for the implementation? In other words, are they happy to support your implementation? 

[bruce_ren]

hi @alanz , most challenges are related to Helm Chart (this is usually the preferred way to do Kubernetes deployment). Things like how to write Helm Charts to deploy Secrets and ConfigMap which we use to mount iiq.properties, log4j.properties and keystore files to pods where IIQ is running. No I don't think we asked the SailPoint product team to review the design.

[Manila]

A central principle of the modern container-based is that the container should be immutable. If your container is immutable and the files change, this might mean your running container was hacked and run-time container security alerts on that. You have to make some tradeoff choices that will drive your image and kubernetes design. Make the right decisions up front to meet your requirements.

If you have a container that expands the war file when it starts, that would violate that principle. So do you expand the war when you build the image, making a very large image? If you add the war to the image, you are also binding that image for dev, test, prod, etc. because the war has the iiq.properties, hbm files, branding.

A variation on that is to have the "unbranded" image download the the iiq.properties, hbm files, branding at startup. Or you can inject the values for the iiq.properties as environment variables and the startup will update the iiq.properties as needed. These will also break the immutable principle.

A different choice is to mount the webapps folder outside of the container and put controls around that.

Maybe the best choice is to not force IIQ into the traditional image model and instead think of it as inseparable from the devops pipeline. The devops pipeline will build the image on demand, publish to the repo, then start your orchestrator.  The image in the repo is temporal and rebuilt on every deployment.

The orchestrator (k8s, Container Instances, etc.) will add the environment variables, mount storage and secrets etc as needed and has its own challenges.

I would make sure the container design can run anywhere and not have dependencies on Docker, ECS, AKS etc. so that they work the same in developer environment and production.

[binotechm]

We are considering IIQ/K8S based solution. Did anyone successfully implement in Prod? Please advise the challenges you faced and whether your solution fully supported by SailPoint.

[bruce_ren]

hi @binotechm , we did release the K8S based IIQ solution to production (soft-launch) successfully. But the customer eventually cancelled the whole project for other unrelated reason.