IBM Security Verify

 View Only

  • 1.  Helm insallation and ISA fixpak 1

    Posted Wed November 11, 2020 05:56 AM
    Hi,
    we are running ISVA ver 10.0.0.0 on a Kubernetes cluster installed from the official Helm repo (version 1.20).

    What is the 'correct' way to apply the 10.0.0.1 fixpak to this installation?

    Rgds

    ------------------------------
    Anders Domeij
    CGI Sweden AB
    ------------------------------


  • 2.  RE: Helm insallation and ISA fixpak 1

    Posted Fri November 13, 2020 05:42 AM
    Hi Anders,

    There are two parts to consider in an upgrade:
    1. General upgrade release notes for the version
    2. Upgrade method specific to the deployment type (Helm in your case)

    For (1) the following should be read:  https://www.ibm.com/support/pages/urgent-apar-information-ibm-security-verify-access-10001-firmware-upgrade
    There will also be release notes associated with the update package.

    There is also this:  https://www.ibm.com/support/pages/node/6340107
    (It doesn't apply to upgrade from 10.0.0.0 to 10.0.0.1 so should be fine but I include in case others are reading this).

    For upgrade from 10.0.0.0 to 10.0.0.1 there is a specific known issue around configuration snapshot migration when using containers.  The upgraded 10.0.0.1 system doesn't detect the existing 10.0.0.0 snapshot file.  The easiest workaround to this issue is to perform the following step just before the upgrade:

    "exec" into the configuration container and run this command:

    cp /var/shared/snapshots/isva_10.0.0.0_published.snapshot /var/shared/snapshots/isam_9.0.7.1_published.snapshot

    On specifics for a Helm environment:

    My first advice would be to make sure you have a backup of all data before attempting the upgrade.  This means a backup of the configuration snapshot, LDAP data, and Database data.  This is especially important for Helm if you are using dynamic provisioning because it will delete your persistent volumes if you delete the associated release.

    The simplest upgrade is to use the "helm upgrade" process.  In this case you would simply:
    1.   Update the values.yaml file and change the repository parameter to point to ibmcom/verify-access:10.0.0.1
    2.   run the "helm upgrade <application> <chart> -f <values file>" command.
    You must have sufficient nodes available to allow new versions of the Verify Access containers to start on a different node from the originals.  This is because of the anti-affinity rules in the charts.  It might be a good idea to modify the affinity settings in the chart to make the rules a preference instead of a requirement to allow in-place upgrade on the same node.

    As an alternative approach, you could delete the current application and then create a new one with the updated values file.  You must be really careful if you use this approach and you are using dynamic provisioning because the delete step will likely delete you persistent volumes.  If you are using PVCs that you manually created (non-dynamic) then these are not deleted and will be picked up by the new application when it starts (based on existingClaim names specified in the values.yaml).

    I hope this helps.  I strongly suggest thoroughly testing and getting familiar with the upgrade process before attempting on any live system (including the backup/restore so you know you will recover if anything goes wrong).

    Jon.

    P.S. I have created a new (v1.21) Helm Chart for Verify Access with some enhancements you might find interesting.  It is not officially published yet but it is a branch of the IBM-Security/helm-charts Github repo.  Upgrading to a new chart version would require similar steps to the above upgrade I think.  Probably best not to attempt both at the same time though.

    ------------------------------
    Jon Harry
    Consulting IT Security Specialist
    IBM
    ------------------------------

    Original Message


  • 3.  RE: Helm insallation and ISA fixpak 1

    Posted Fri November 13, 2020 06:46 AM
    Hi Jon,

    Thanks for the 'step-by-step'!
    I had seen your Helm ver 1.21 update post and appreciated the changes you've included :-)

    Does 1.21 include fp 1 if I where to do a fresh install, or is fp1 applied after?
    Or rather in my case -- if I update to 1.21, do I automatically get a container with fp1 included.

    Going thru my installation notes, I see that in my values.yaml I have 

    verify-access-config:
    global:
    container:
    <snip>
      dataVolume:
        existingClaimName: "isva-config-volume"
        size: 20Gi
      image:
        <snip>
      imageCredentials:
        <snip>
      persistence:
        enabled: true
        useDynamicProvisioning: true

    which (after reading your post) seems contradictory since I have both an existing claim name and useDynamicProvisioning:true

    Does one setting override the other (if so which overrides which)
    or is it to be interpreted as
    Use dynamicProvisioning except for those datavolumes that are explicitly set?

    Rgds

    ------------------------------
    Anders Domeij
    CGI Sweden AB
    ------------------------------

    Original Message


  • 4.  RE: Helm insallation and ISA fixpak 1

    Posted Fri November 13, 2020 08:42 AM
    Hi Anders,

    I've made 2 more enhancements to the 1.2.1 chart.

    • It now sets dynamic PVCs not to be removed by a "delete" of the chart.  I think this is safer.  It doesn't affect you since you're using existingClaims already.
    • I have changed the antiAffinity rules to be "preferred" instead of "required" so that pods can start on same node if no other available.  This change is only helpful after migration to the 1.2.1 chart - a workaround is still needed to get to this chart if there are not sufficient nodes to allow new versions to start on a different node from current version.

    To answer your questions:

    If you have "existingClaimName" set in your values.yaml then this PVC will be used and value for dynamic provisioning is not used.  If all your PVCs are set with an "existingClaimName" then the value for "dynamicProvisioning" is not being used... however, it would be a good idea to set it to false to make things more consistent.

    The chart version is independent to whether you're using 10.0.0.0 or 10.0.0.1.  The image used is specified in the values.yaml file in the repository parameter.  Whether you update the image first, or the chart version first is up to you.  Personally I would update to the v1.2.1 chart first because once that is done, you'll have the updated anti-affinity rules which may help avoid other issues.

    Until you get to the latest v1.2.1 version of the chart, you may find that when you do a "helm upgrade" you end up with pending pods which are not scheduled because of affinity rules.  If this is the case, you can work-around by manually deleting (kubernetes delete pod ...) the running pod so that the pending one can start.  When you do this, ANOTHER pending pod will be shown but this will be removed once the updated pod is started.

    Since you are using non-dynamic PVCs, you could also decide to simply delete the current application (helm delete ...) and then create a new application with the new v1.2.1 chart (but pointing at the same PVCs).

    Interested to hear how you get on.

    Jon.

    ------------------------------
    Jon Harry
    Consulting IT Security Specialist
    IBM
    ------------------------------

    Original Message