IBM Verify

IBM Verify

Join this online user group to communicate across Security product users and IBM experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only
  • 1.  Deployment for ISVA on kubernetes (challenges)

    Posted Thu April 10, 2025 10:23 AM

    Hi, the employer I work for is trying to get ISVA setup on Oracle Kubernetes (which should not be much different from doing this on Amazon Cloud/Google Cloud for example). They have setup more like a "minikube" environment with the deployment guide that's made available by Jon Harry. Please note that I cannot find that guide anywhere online: The link that I see in README.md is https://www.securitylearningacademy.com/course/view.php?id=6860, but when I login it says "This course is currently unavailable to students". 

    The first thing I notice is how little documentation I find for setting this properly on Kubernetes. I am more familiar with the SVA running on VMware as a virtual appliance and I cannot translate that to how things are on Kubernetes. For example:

    1) Which pod would be running the policy server?

    2) We have a primary & secondary policy server on our on-prem environment, so how do I go about setting those on Kubernetes?

    3) Currently we have separate on-prem reverse proxy clusters (2 appliances for internal application traffic and 2 in DMZ for serving external application traffic) - these share a common policy server on-prem. Is that design possible on Kubernetes? For example, if we have 2 wrp pods in Kubernetes cluster A and another 2 wpd pods in Kubernetes Cluster B, can they share the policy server sitting in Cluster C?

    Apologize in advance if my questions aren't clear, but documentation on trying to set this up is really sparse. I would also appreciate if someone can point me in the correct direction as far as documentation is concerned. 



    ------------------------------
    Giriraj Dave
    ------------------------------


  • 2.  RE: Deployment for ISVA on kubernetes (challenges)

    Posted Thu April 10, 2025 12:20 PM

    HI

    This link is important

    https://docs.verify.ibm.com/ibm-security-verify-access/docs/containers

    1.All configurations are done on config pods -> pdmgrd run here ( icr.io/ivia/ivia-config:11.0.0.0_IF1) (you can only have 1 pod)
    2.All remaining pods( Reverse proxy , you can configure 1 rp configurations and run mulitiple pods of this rp configuration) , RP pod will fetch configuration from config container during startup. (slight different from appliance where you create multiple RP instances) . Here 1 instance of same configuration can run in many pods. (like may be you would like to run 3 pods for HA/Redundancy) -> icr.io/ivia/ivia-wrp:11.0.0.0_IF1
    3.DSC -> incase you are using for distributed session cache ( can have 4 pods) primary , secondary , tertiary , quaternary -> icr.io/ivia/ivia-dsc:11.0.0.0_IF1, kind of you can create different deployment each having 1 pod. All configurations are in config pod. when DSC pod starts, it will fetch the snapshot from config pod.

    4.Runtime pod -> similar to RP. It provides AAC/Federation capabilities . All configurations are with config pod. when pod starts, it will fetch snapshot from config pod
    6.ISVAOP -> Next Gen OpenID provider -> icr.io/ivia/ivia-oidc-provider:25.03 . It will have its own separate configuration in config map (independent of config container) . Rich in OpenID /Oauth capabilities.

    https://github.com/IBM-Security/isam-support/tree/master/config-example/docker



    ------------------------------
    Tushar
    Tushar
    ------------------------------



  • 3.  RE: Deployment for ISVA on kubernetes (challenges)

    Posted Thu April 10, 2025 11:35 PM

    Once you have the basics

    here are the Answers to questions

    1) Which pod would be running the policy server?

    Config pod runs the pdmgrd( policy server) which has capability to create acls, pods, objectspaces , RP etc

    2) We have a primary & secondary policy server on our on-prem environment, so how do I go about setting those on Kubernetes?

    There is no concept of primary /secondary in containers.

    Config container is the only pod where you can do the configuration. Snapshot manager is the proxy which can hold snapshot from config pod so that incase you got lot many RP,DSC,Runtime pods then they could just fetch it from snapshot manager , instead of directly from config container.

    3) Currently we have separate on-prem reverse proxy clusters (2 appliances for internal application traffic and 2 in DMZ for serving external application traffic) - these share a common policy server on-prem. Is that design possible on Kubernetes? For example, if we have 2 wrp pods in Kubernetes cluster A and another 2 wpd pods in Kubernetes Cluster B, can they share the policy server sitting in Cluster C?

    All RPs can share same config pod( its just a url they should be able to reach which is a Ingress to config pod)

    2 WRP pod on Kubernetes cluster A will on startup fetch the config snapshot from configuration pod and will start . 
    similarly, 2 WRP pods in cluster B can connect to ingress of Policy server in cluster C . 

    Yes. both can reach connect to Policy server in cluster C ( if the ingress allows which it should)

    (Optional)
    additionally, you can make use of snapshotmanager which is a proxy to config container which holds snapshot

    A snapshot is a collection of all configuration which pods will fetch.

    When you perform any change on config pods. it will publish the change to snapshot manager . 

    In simplest of deployment 



    ------------------------------
    Tushar
    Tushar
    ------------------------------



  • 4.  RE: Deployment for ISVA on kubernetes (challenges)

    Posted Tue April 15, 2025 03:06 PM

    Hi Tushar, thank you very much for the clarification. I have a couple follow-up questions based on your reply. In the on-prem env. we also make use of SCIM for user self-help (password reset made by the user themselves) and we store the email id and challenge questions for accounts that have completed profile setup. I believe this would be made on the iviaruntime pod? On the kubernetes environment we have below:

    $ kubectl get pods -o wide

    NAME                           READY   STATUS             

    iviaconfig-6cc87c4d8b-m2jvh    1/1     Running            
    iviadsc-7fb88fd75-kl6qf        0/1     Running            
    iviaop-86cb668669-72sp6        0/1     Running            
    iviaruntime-57f7888596-tmx77   0/1     Running            
    iviawrprp1-5bf8b54697-2z2tr    0/1     Running            
    openldap-569c48859f-gdj5m      1/1     Running            
    postgresql-786599b9cd-h6j28    0/1     CrashLoopBackOff   

    1) So, if we use postgresql as the DB in lower env, then is that the pod that gets used by iviaconfig for runtime and config db? How do we go about achieving HA for both postgresql & iviaconfig? Do we just specify in kubernetes the minimum number of pods that should be running? Let's say 2 for both postgresql & iviaconfig?

    2) The SCIM portion, would that be running on iviaruntime? If yes, then how do we ensure HA for that? Same concept that we specify the minimum number of pods as 2?

    Apologize for my lack of understand of basic kubernetes, but it's new for everyone here and we don't have a whole lot of answers.

    Again, thank you for your time and help on these.



    ------------------------------
    Giriraj Dave
    ------------------------------



  • 5.  RE: Deployment for ISVA on kubernetes (challenges)

    Posted Wed April 16, 2025 04:31 AM

    HI

    Answers:

    1. Runtime pod is hosting JVM ( which provides AAC/federation functionalities) . For Runtime pod, Transactional and scim related information are stored in Runtime Database ( HVDB ) , which is where PostGreSQL ( it is outside the runtime pod) and you can make use of postgres HA . It supports Postgres HA.
      1. https://www.ibm.com/docs/en/sva/11.0.0?topic=environment-runtime-database
      2. The other database used by Runtime is configuration database, which for example. stores configuration information about scim( ldap FQDN,IP, attribute mapping etc). IVIA 11 has an option to run configuration database within containers or external to the runtime container. If you choose to run it external then you would need to manage that. Required schema can be downloaded from config container and use that to build the postgres image.

      3. Its best Postgres HA is managed outside the product and HA should be taken care outside the product. Review support statement about postgres image that comes with IVIA https://www.ibm.com/docs/en/sva/11.0.0?topic=support-container-image-postgresql
      4. Required postgres related schema you can download from config container  pod , file downloads section and build postgres image and use that in production.
    2. SCIM functionality runs under IVIAruntime  pod You can have many runtime pods. Postgres you need to manage accordingly.


    ------------------------------
    Tushar
    Tushar
    ------------------------------